Method for transmitting information over an intelligent low power serial bus

ABSTRACT

A low power, single master, variable clock rate, daisy-chainable, serial bus connects a bus dispatch in a base station (master) to a chain of one or more daisy-chained peripheral devices (slaves). The bus has a bidirectional serial data line, a bidirectional clock line, unidirectional interrupt line, power and ground lines. Data and commands are sent from the base station to a peripheral device, and data is received from the peripheral device by the base station by configuring each peripheral device on the bus to receive data and clock signals from the base station in an idle mode of operation. Upon a command send being transmitted by the base station, all peripheral devices on the serial bus between the base station and an addressed peripheral device remain in the idle mode and the addressed peripheral device is connected to the bus so that clock and data signals on the bus to are passed to the peripheral device. When the peripheral devices on the bus are in the idle mode of operation, and the base station transmits a command get to an addressed peripheral device, the addressed peripheral device and all peripheral devices between the addressed peripheral device and the base station are reconfigured to transmit clock and data signals from the addressed peripheral device to the base station.

REFERENCE TO MICROFICHE APPENDIX

Appendix A, which is a part of the present disclosure, is a microficheappendix consisting of 2 sheets of microfiche having a total of 109frames. Microfiche Appendix A is a listing of one embodiment of the busdispatch control software of this invention, which is described morecompletely below, and is incorporated herein by reference in itsentirety.

Appendix B, which is a part of the present disclosure, is a microficheappendix consisting of 2 sheets of microfiche having a total of 179frames. Microfiche Appendix B is a specification for one embodiment of alow power serial bus, and is incorporated herein by reference in itsentirety.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

This invention relates generally to digital serial bus technology andmore particularly, to low power digital serial bus technology.

BACKGROUND OF THE INVENTION

Existing personal computers offer multiple external peripheralinterfaces for attaching multiple peripheral devices to a host computer.An Apple Computer, Inc. Macintosh personal computer, for example,typically has (i) an Apple Desktop Bus interface for a keyboard and amouse, (ii) a Small Computer System Interface (SCSI) for disk drives,and (iii) an RS-232/RS-422 interface for a printer and a modem. Allthree interfaces are necessary for the Macintosh personal computerbecause not any one of these standard interfaces can accommodate all theperipheral devices.

On a small, hand-held portable computer such as a so-called "PalmTopcomputer" or "Personal Communicator", however, providing severaldifferent external peripheral interfaces presents a number of problems.From a user's perspective, it is confusing to employ multiple differentinterfaces, each having its own protocol and connector. Further, theremay not be an adequate amount of physical space on the PalmTop computerto provide numerous connectors and the power requirements of separatestandard peripheral interfaces are onerous for battery powered hand-heldcomputers. In addition, the cost of supporting multiple differentexternal interface standards in terms of number of logic gates andnumber of connector terminals is significant when manufacturing for theconsumer computer market.

Even if a host PalmTop computer were to use only one of the abovestandard interfaces to accommodate a limited set of peripheral devices,and even if this standard interface was redefined to require less power,such a conventional interface would either be low performance, e.g., theApple Desktop Bus runs at about 10 KBits/second, or complex to use,e.g., SCSI requires configuring peripherals, attaching specialterminators, and shutting down the computer for reconfiguration.

Alternatively, a new external interface standard called IEEE P1394 couldbe used. Although this new interface standard potentially satisfies someof the performance and ease-of-use requirements of a PalmTop computerperipheral interface, the interface nevertheless requires additionalcomplex, non-standard, interface circuitry to the peripherals. Suchcomplex interface circuitry would make it difficult for small, lowvolume peripheral manufacturers to make simple peripheral devices at lowcost. Moreover, employing IEEE P1394 would also require the PalmTop hostcomputer to incorporate an expensive support chip having approximately20,000 gates.

Accordingly, a single, low power, easy-to-use, high performance, serialbus suitable for use on a hand-held PalmTop host computer with a widevariety of peripheral devices is needed.

SUMMARY OF THE INVENTION

In accordance with the principles of this invention, an intelligentdaisy-chainable serial (IDCS) bus structure is used to connect one ormore peripheral devices to a base station such as a palm-top computer.The IDCS bus supports a novel protocol wherein in a first mode ofoperation, information is clocked over a first channel using a clocksignal on a second channel and in a second mode of operation,information is clocked over the second channel using a clock signal onthe first channel. This protocol provides an efficient unambiguousmethod for distinguishing commands for IDCS bus operations from datatransmitted over the IDCS bus.

The IDCS bus of this invention allows a user to easily attach aperipheral device to the base station without any knowledge of howeither a computer, a peripheral device driver, or the peripheral deviceitself works. The IDCS bus supports hot plugging and removal ofperipheral devices.

A bus dispatch unit within the base station detects when either aperipheral device has been added or removed from the IDCS bus andautomatically reconfigures the IDCS bus appropriately. Specifically,upon detecting a change in the bus configuration, the bus dispatch unitautomatically defines an address for each peripheral device on the IDCSbus and configures a software driver, sometimes called a peripheralclient, for each peripheral device in the process of configuring theIDCS bus with the newly attached or detached peripheral device. Asimilar process is performed on power-up of the base station for anyperipheral devices connected to the base station by the IDCS bus.

The IDCS bus of this invention is highly flexible and allows users toconnect the base station to a diverse variety of peripheral devices,including other base stations, scanners, bar code readers, thermometers,printers, keyboards, cameras, mass storage, and other such peripheraldevices. The IDCS bus does not require addition of complex interfacecircuitry to a peripheral device. Instead, the IDCS bus requires only abus interface circuit that includes a bus interface integrated circuit,that is referred to herein as a MBIC, and a microcontroller. The businterface circuit is standard independent of the peripheral device type.Alternatively, the bus interface circuit can be included within themicrocontroller. Consequently, independent of the volume of peripheraldevices of a particular type, the bus interface circuit and themicrocontroller are the same as those used in other types of peripheraldevices. Therefore, the low volume peripheral device seller is not facedwith developing a complex non-standard part to interface the peripheraldevice with the IDCS bus of this invention.

The IDCS bus supports a broadband of communication frequencies and allcommands to configure the IDCS bus are transmitted at the maximumfrequency supported. Information passed to a particular microcontrollerin a peripheral device is transmitted at a speed defined by theparticular microcontroller.

In addition, failure of a microcontroller within a peripheral devicedoes not affect operation of the IDCS bus. The bus interface circuit canbe configured and operated without support from the peripheral devicemicrocontroller. Specifically, the bus interface circuit can passcommands and data through the peripheral device even if themicrocontroller is defective or the peripheral device is powered downbecause the bus interface circuit is powered at all times when the busdispatch unit is active.

The bus dispatch unit, sometimes referred to simply as bus dispatch,within the base station includes the hardware and software subsystemsthat support the IDCS bus of this invention. The bus dispatch unit isthe sole bus master of the IDCS bus for command and control purposes,i.e., the bus dispatch unit initiates all commands that result in datatransfer. For example, in response to an appropriate command from thebus dispatch unit, each peripheral device on the IDCS bus can driveclock and data lines of the IDCS bus thereby providing data to busdispatch unit. Each peripheral device, in this embodiment, isresponsible for indicating to the bus dispatch unit that datatransmission from the peripheral device is complete.

The last peripheral device on the IDCS bus is referred to as a lastperipheral device. All other peripheral devices on the IDCS bus, exceptthe last peripheral device, are referred to as mid-peripheral devices.Specifically, the bus dispatch unit assigns each peripheral device onthe IDCS bus one of a first status and a second status where a lastperipheral device on the bus is assigned the second status and all otherperipheral devices on the bus are assigned the first status.

Signals on the IDCS bus that travel in a direction from the lastperipheral device towards the bus dispatch unit travel in an upstreamdirection. Conversely, signals that travel in a direction from the busdispatch unit towards the last peripheral device travel in a downstreamdirection. Thus, upstream as used herein means towards the base stationand downstream means away from the base station. Sometime, the basestation is referred to as the host computer.

The IDCS bus of this invention is fully interrupt driven. Peripheraldevices send interrupts over a bus interrupt line to get the attentionof the bus dispatch unit. When the bus dispatch unit senses aninterrupt, the bus dispatch unit performs an interrupt poll to determinethe source and the nature of the interrupt. Interrupts are serviced bythe bus dispatch unit once the current command cycle is complete. Aninterrupt signals that a peripheral devices requires servicing. Forexample, an interrupt can indicate when a peripheral device has beenattached or detached from the IDCS bus, and when an IDCS bus erroroccurred.

As indicated above, the bus dispatch unit in the base station controlsoperation of the IDCS bus using commands that are transmitted on theIDCS bus. A command is a message sent to a bus interface circuit in aparticular peripheral device, or to the bus interface circuits in allthe peripheral devices on the IDCS bus from the bus dispatch unitdirecting either the bus interface circuit or a microcontroller in theperipheral device to perform an operation.

A command is sent to a peripheral device when the peripheral device isin an idle mode, either a mid-idle mode or a last-idle mode depending onthe status of the peripheral device. Commands issued by the bus dispatchunit are propagated downstream to each of the bus interface circuits andare acted upon by each bus interface circuit and/or peripheral device ina manner appropriate for that peripheral device. The particular actiontaken depends both upon the state of the bus interface circuit and thedestination address within the command.

In this embodiment, each command includes two bytes. A first byteidentifies the peripheral device for which the command is intended viaan address and a second byte includes an op code that identifies theoperation to be performed. There are four types of command sequences,hardware commands, software commands, command send and command get.Commands send and get are software commands, but are consideredseparately because the command sequences for commands send and get aredifferent from the command sequences for the other software commands.Hardware commands are intended for a bus interface circuit in aparticular peripheral device and are not passed along to the peripheraldevice's microcontroller.

Thus, hardware commands are sent as a single command word consisting oftwo bytes both of which are read and interpreted by the bus interfacecircuit in the addressed peripheral device. Hardware commands are sentat the maximum IDCS bus speed, e.g., 14.75 Mbps.

Software commands are commands intended for a peripheral device'smicrocontroller. Software commands also are sent in one two byte commandword with the exception of commands send and get, which involve datatransactions and thus follow different sequences. The bus interfacecircuit reads the command word, and if the bus interface circuit (MBIC)determines that the command word is a software command for itsmicrocontroller, the MBIC passes only the second byte of the commandword that contains a command code to the microcontroller.

The bus dispatch unit uses a command send to inform a peripheral devicethat the bus dispatch unit is about to transmit data to the peripheraldevice. Command send may be transmitted over the IDCS bus at twodifferent speeds. The first byte in command send is intended only forthe bus interface circuits and so is sent at the maximum bus speed. Thesecond byte is passed to the microcontroller and so the second byte istransmitted at a speed compatible with the microcontroller as is thesubsequent data. Command send is followed directly on the IDCS bus bythe data packet or packets and then an end of transmission command tothe addressed peripheral device that tells the peripheral device thatthe transaction is completed.

Command get is used by the bus dispatch unit to inform a peripheraldevice to send data to the bus dispatch unit. The command get sequencebegins with the issuance of command get by the bus dispatch unit.Command get also may be transmitted over the IDCS bus at two differentspeeds. The first byte in the command is intended only for the businterface circuits and so is sent at the maximum bus speed. The secondbyte is passed to the microcontroller and so the second byte istransmitted at a speed compatible with the microcontroller.

When the addressed peripheral device receives command get, theperipheral device responds by sending a start of transmission commandSOT that configures the IDCS bus to transmit data from the peripheraldevice to the bus dispatch unit. Start of transmission command SOT isfollowed by data packet or packets which are followed by an end oftransmission command EOT that tells each bus interface circuit on theIDCS bus and the bus dispatch unit that the transaction is completed.The bus dispatch unit transmits an end of transmission command EOT toconfirm that the data was received.

End of transmission command EOT is generated by the bus dispatch unit atthe end of each bus transaction. The bus interface circuits in each ofthe peripheral devices on the IDCS bus continuously monitor for commandEOT. Each peripheral device is therefore able to detect the end of allbus transactions.

According to the principles of this invention, data and commands aresent from a base station to a peripheral device, and data is receivedfrom the peripheral device by the base station over a serial busconnecting the peripheral device to the base station by configuring eachperipheral device on the serial bus to receive data and clock signalsfrom the base station in an idle mode of operation. Each peripheraldevice includes (i) upstream buffers coupled to the serial bus, (ii)downstream buffers coupled to the serial bus, and (iii) peripheraldevice buffers that can be coupled to, and decoupled from the upstreambuffers.

Upon a command send being transmitted over the serial bus by the basestation, all peripheral devices on the serial bus between the basestation and an addressed peripheral device maintain the idle modeconfiguration. The addressed peripheral device reconfigures upstreambuffers that are connected to the serial bus so that clock and datasignals upstream buffers pass clock and data signals on the serial busto peripheral device buffers.

After sending the command send, the base station clocks data to theaddressed peripheral device. Upon completion of the data transmission,the base station transmits an end of transmission command. In responseto the end of transmission command, the addressed peripheral devicereconfigures the upstream buffers to transmit clock and data signals onthe serial bus to downstream buffers in the address peripheral device.

When the peripheral devices on the serial bus are in the idle mode ofoperation, and the base station transmits a command get over the serialbus to an addressed peripheral device, the addressed peripheral deviceand all peripheral devices on the serial bus between the addressedperipheral device and the base station are reconfigured to transmitclock and data signals from the addressed peripheral device to the basestation. In reconfiguring the addressed peripheral device and allperipheral devices on the serial bus between the addressed peripheraldevice and the base station, the downstream buffers in a peripheraldevice connected directly to the base station by the serial bus arereconfigured so that clock and data signals can be received from anotherperipheral device on the serial bus.

The upstream and downstream buffers in all peripheral devices on theserial bus between the addressed peripheral device and the peripheraldevice connected directly to the base station by the serial bus so thatthe downstream buffers pass clock and data signals to the upstreambuffers. The upstream and peripheral buffers in the addressed peripheraldevice are reconfigured so that the peripheral buffers pass clock anddata signals to the upstream buffers.

In response to the command get, the addressed peripheral device issues astart of transmission command, and in response to the start oftransmission command, the downstream buffers in the peripheral deviceconnected directly to the base station by the serial bus are coupled tothe upstream buffers so that the downstream buffers pass clock and datasignals to the upstream buffers. After issuing the start of transmissioncommand, the addressed peripheral device transmits clock and datasignals to the base station over the serial bus.

Upon completion of the data transmission, the address peripheral devicetransmits an end of transmission command. In response to the end oftransmission command, the addressed peripheral device and all of theperipheral devices on the serial bus are reconfigured. Specifically, allof the peripheral devices on the serial bus between the addressedperipheral device and the base station reconfigure upstream anddownstream buffers so that the upstream buffers pass clock and datasignals to the downstream buffers. The addressed peripheral devicereconfigures the upstream buffers to pass clock and data signals to thedownstream buffers upon the base station transmitting an end oftransmission command.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a perspective view of one embodiment according to the presentinvention of an operating bus having a host computer and two peripheraldevices.

FIGS. 2A-2H are diagrams showing examples of various bus configurationsaccording to the principles of this invention.

FIG. 3 is a block diagram of the intelligent daisy chain serial bus ofthis invention.

FIG. 4 is more detailed block diagram of the intelligent daisy chainserial bus of this invention.

FIG. 5A illustrates transmission of data over IDCS bus 150 according tothe principles of this invention.

FIG. 5B illustrates transmission of a command over IDCS bus 150according to the principles of this invention.

FIGS. 5C show the structures for one embodiment of a command accordingto the principles of this invention.

FIG. 6 is a flow diagram for the operation of bus dispatch 305.

FIGS. 7A and 7B are detailed block diagrams of a first embodiment and asecond embodiment, respectively of an integrated circuit that supportsthe protocols for the intelligent daisy chain serial bus of thisinvention.

FIG. 8 is a state diagram for a state machine within the bus statecontrol logic circuit shown in FIGS. 7A and 7B.

FIG. 9 is a block diagram of one embodiment of a part of the interruptlogic circuit shown in FIGS. 7A and 7B.

FIG. 10 is a block diagram of one embodiment of the special commandlogic circuit shown in FIGS. 7A and 7B.

FIG. 11A is a logic circuit diagram of control circuitry for the counterof FIG. 10.

FIG. 11B is a diagram of the counter of

FIG. 10 and related circuitry used to generate control signals.

FIG. 12 is a timing diagram that illustrates the operation of thecircuitry in FIGS. 10, 11A and 11B.

FIG. 13 is a schematic diagram of the synchronization circuit of thisinvention.

FIG. 14 illustrates one configuration of the integrated circuit of FIG.7B within a peripheral device.

FIG. 15 is one embodiment of a wake-up circuit as well as latch-upprotection and interrupt propagation circuitry according to theprinciples of this invention.

FIG. 16 is a block diagram illustrating the software and hardwarestructure for the IDCS bus of this invention.

FIG. 17 is a process flow diagram for one embodiment of the wake-upsequence of this invention.

FIG. 18 is a process flow diagram for one embodiment of the power onsequence of this invention.

FIG. 19 is a process flow diagram for one embodiment of the bus resetsequence of this invention.

FIG. 20 is a process flow diagram for one embodiment of the addressassign sequence of this invention.

FIG. 21 is a process flow diagram for one embodiment of the peripheralconfiguration sequence of this invention.

FIG. 22 is a process flow diagram for one embodiment of the Getperipheral ID sequence within the peripheral configuration sequence ofthis invention.

FIG. 23 is a process flow diagram for one embodiment of the locateperipheral client sequence within the peripheral configuration sequenceof this invention.

FIG. 24 is a process flow diagram for one embodiment of the loadperipheral client sequence in the locate peripheral client sequence.

FIG. 25 is one embodiment of the attach peripheral client sequencewithin the peripheral configuration sequence of this invention.

FIG. 26 is a process flow diagram of one embodiment of the service bussequence of this invention.

FIG. 27 is a process flow diagram of one embodiment of the start IRQPoll sequence within the service bus sequence of this invention.

FIG. 28A is a process flow diagram of one embodiment of the IRQ Poll(Next) sequence within the service bus sequence of this invention.

FIG. 28B is a process flow diagram of one embodiment of the peripheralattachment sequence within the service bus sequence of this invention.

FIG. 29 is a process flow diagram for the command sequencer within theservice bus sequence of this invention.

FIG. 30 is a process flow diagram of one embodiment of the error servicesequence within the service bus sequence of this invention.

FIGS. 31A and 31B define timing relationships for transmission ofsignals over the IDCS bus of this invention.

FIGS. 32A to 32C illustrate the various signal interfaces according tothe principles of this invention.

DETAILED DESCRIPTION

In accordance with this invention, an intelligent daisy-chainable serial(IDCS) bus structure is used to connect one or more peripheral devicesto a base station such as a palm-top computer. The IDCS bus supports anovel protocol wherein in first mode of operation, information isclocked over a first channel using a clock signal on a second channeland in a second mode of operation, information is clocked over thesecond channel using a clock signal on the first channel. As explainedmore completely below, this protocol provides an efficient unambiguousmethod for distinguishing commands for the IDCS bus operations from datatransmitted over the IDCS bus.

In one embodiment, as shown in FIG. 1, IDCS bus 150 connects basestation 100 to between one and six serially-connected peripheraldevices, e.g., peripheral devices 110 and 120. Specifically, basestation 100, which is a battery-powered hand-held computer with atouchscreen 109, has a connector 101 capable of accepting a connector112 on cable 113 from peripheral device 110. In another embodiment,peripheral device 110 is attached directly to base station 100 viaconnector 101, i.e., without cable 113. Base station 100 is the hostcomputer for IDCS bus 150.

To couple a second peripheral device, e.g. peripheral device 120, tobase station 100, a second cable 123 with connector 122 is connected toa connector 111 of peripheral device 110. Since only two peripheraldevices 110 and 120 are used in this example, connector 121 ofperipheral device 120 is not used. The serial connection of peripheraldevices 110, 120, as illustrated in FIG. 1, is commonly referred to asdaisy-chaining.

IDCS bus 150 of this invention starts in base station 100 and extendsthrough connector 101, connector 112, cable 113, peripheral device 110,connector 111, connector 122, cable 123, and peripheral device 120 toconnector 121. Within devices 110 and 120 is an integrated circuit (notshown in FIG. 1) that controls transmission of messages and data eitherthrough the peripheral device to another peripheral device on IDCS bus150 or to a microcontroller (not shown in FIG. 1) within the peripheraldevice. Thus, as shown in FIG. 1, each peripheral on IDCS bus 150contains two interface connectors, an upstream connector that iselectrically closer to base station 100, and a downstream interfaceconnector that is electrically closer to a downstream peripheral device,or in the case of the last peripheral device, e.g. peripheral device120, is unused. The integrated circuit in last peripheral device 120 isconfigured to block transmission of signals to the downstream interfaceconnector, i.e., the integrated circuit terminates IDCS bus 150 inperipheral device 120.

IDCS bus 150 of this invention allows the user to easily attach aperipheral device to base station 100 without any knowledge of howeither a computer, a peripheral device driver, or the peripheral deviceitself works. IDCS bus 150 supports hot plugging and removal ofperipheral devices. A bus dispatch unit, that is described morecompletely below, in base station 100 detects when either a peripheraldevice has been added or removed from IDCS bus 150 and reconfigures IDCSbus 150 appropriately. The bus dispatch unit automatically defines anaddress for each peripheral device on IDCS bus 150 and configures asoftware driver, sometimes called a peripheral client, for eachperipheral device in the process of configuring IDCS bus 150 with thenewly attached or removed peripheral device.

IDCS bus 150 is highly flexible and allows users to connect base station100 to a diverse variety of peripheral devices, including other basestations, scanners, bar code readers, thermometers, printers, keyboards,cameras, mass storage, and other such peripheral devices.

IDCS bus 150 does not require addition of complex interface circuitry toa peripheral device. Instead, as described more completely below, IDCSbus 150 requires only an interface circuit, that is standard independentof the peripheral device type, and a microcontroller. Alternatively, theinterface circuit can be included within the microcontroller.

Consequently, independent of the volume of peripheral devices of aparticular type, the interface circuit and the microcontroller are thesame as those used in other types of peripheral device. Therefore, thelow volume peripheral device seller is not faced with developing acomplex non-standard part to interface the peripheral device with IDCSbus 150.

IDCS bus 150 supports a broadband of communication frequencies and allcommands to configure IDCS bus 150 are transmitted at the maximumfrequency supported. In addition, failure of a microcontroller within aperipheral device does not affect operation of IDCS bus 150. Theinterface circuit can be configured and operated without support fromthe peripheral device microcontroller.

In addition to IDCS bus 150 of this invention, the bus structure of thisinvention also supports conventional communication protocols forcomputer peripheral devices and computers, power input for rechargingbatteries in base station 100, and telephone connections. However, thesefeatures are not essential to IDCS bus 150 and IDCS bus 150 can beimplemented and used without any one or all of these features. In oneembodiment, a passive serial bus adapter is used to convert the lowvoltage signals on IDCS bus 150 to the higher voltage signals used byconventional passive serial interfaces, such as the RS-232 serialinterface or the RS-422 serial interface, which are typically notdaisy-chained. Thus, for example, in a conventional RS-232 serialinterface only a single passive adapter is allowed at base station 100.Although telephony adapters are daisy-chained, only one device in atelephone daisy chain is allowed to be operational at a given time, i.e.there is no provision for bus contentions.

Charger peripherals inherently cannot be daisy-chained. A batterycharger must be connected either directly to connector 101 of basestation 100 without the use of cable 113 or to a peripheral device thatis connected directly to connector 101. Thus, no IDCS bus cable evercarries the charger level currents and no peripheral devices passthrough the charger level voltages and currents. Hence, in thisconfiguration, cables 113, 123 carry only signal levels associated withIDCS bus 150 and so IDCS bus operates with low power supply voltages,e.g., 3.3 volts.

Peripheral Device Configurations Supported By IDCS Bus

As explained above, previously, interconnection of a variety ofperipheral devices to a computer required multiple peripheral deviceinterfaces. In contrast, the peripheral device interface of thisinvention and the IDCS bus protocol can be used to support a widevariety of peripheral devices as illustrated in FIG. 2A to 2H. Forexample, FIG. 2A shows base station 100 connected to a snap-onperipheral device 210A. In this interconnection configuration,peripheral device 210A connects directly to the body of base station 100and so no cable is required. A screw may be provided on peripheraldevice 210A to securely connect snap-on peripheral device 210A to basestation 100. In FIG. 2A, both connector 212 and a two terminal tip andring connector 213, couple peripheral device 210A to base station 100.Snap-on peripheral devices include, for example, modems, scanners,CD-ROM players, radio frequency links, and tricorder sensor arrays. Notethat snap-on peripheral device 210A is a pass-through peripheral deviceand so has connector 212 coupled to connector 214.

FIG. 2B shows base station 100 connected to a cabled peripheral device210B. Cabled peripheral devices may include, for example, ASCIIkeyboards, film printers, CD-ROM juke boxes, laser printers, andtransmitters. Note that cabled peripheral device 210B is also apass-through peripheral device having connector 212 coupled to connector214.

FIG. 2C illustrates base station 100 connected to a computer 219C, suchas a Macintosh personal computer, via a passive RS-422 serial adapter210C. Level shifters are provided in adapter 210C to shift the voltagelevels on the serial lines of connector 212 to RS-422 signal levels andvisa versa. In view of the following disclosure and the standard for theRS-422 serial interface, this level shift circuitry required in adapter210C will be apparent to those skilled in the art. In addition to thelevel shift capability, adapter 210C also supports other peripheraldevices that are coupled to IDCS bus 150 via connector 214.

FIG. 2D shows base station 100 connected to a serial printer 219D via apassive RS-232 serial adapter 210D. Level shifters are provided inadapter 210D to shift the voltage levels on the serial lines ofconnector 212 to RS-232 signal levels and visa versa. In view of thefollowing disclosure and the standard for the RS-232 serial interface,this level shift circuitry required in adapter 210D will be apparent tothose skilled in the art. For example, a single supply RS-232 levelshifter such as that sold by Maxim of 120 San Gabriel Drive, Sunnyvale,Calif. 94086-9892 as Maxim 231 could be used. Again, note that adapter210D in addition to the level shift capability also can supportadditional peripheral devices that are connected to IDCS bus 150 viaconnector 214. While adapters for the RS-422 and RS-232 serialinterfaces are illustrated in FIGS. 2C and 2D, the IDCS bus 150 of thisinvention can transmit signals for any serial interface so long as thevoltage levels of the serial interface are appropriately adjusted.

In FIG. 2E base station 100 is connected to a musical keyboardperipheral 219E via an intelligent serial adapter 210E. Communicationbetween adapter 210E and peripheral 219E may utilize virtually anyserial protocol including MIDI.

FIG. 2F illustrates base station 100 cabled to another base station 210Fusing IDCS bus 150 of this invention.

FIG. 2G shows base station 100 connected to a snap-on pass-throughtelephone dock peripheral device 210G. A battery charger 218, which isconnected to telephone dock 210G, supplies power to base station 100through telephone dock 210G and through connector 212, which connectstelephone dock 210G to base station 100. A printer 229G is the lastperipheral on IDCS bus 150 in this embodiment. Printer 229G is connectedto telephone dock 210G via an intelligent RS-232 adapter 220G.Intelligent RS-232 adapter 220G allows more complex printer protocolsand buffering to be utilized without burdening base station 100 withthose tasks. An RJ11 telephone jack 217 is provided on telephone dock210G to connect the telephone dock to a telephone landline plug (notshown).

FIG. 2H shows base station 100 connected to a snap-on telephone dockunit 210H. Telephone dock unit 210H splits the passive serial portsignals of the bus from other bus signals. Accordingly, telephone dockunit 210H functions as a peripheral device on bus 150 coupled to anotherperipheral device 220H, while at the same time having a printer 219Hconnected directly to telephone dock unit 210H via an RS-232 cable.

Referring back to FIG. 1, since chargers and passive serial adapters areconnected directly to base station 100, novel low power IDCS bus 150 ofthis invention is used to communicate between peripherals 110, 120 andbase station 100. To further describe the features and capability ofIDCS bus 150 of this invention, several terms are defined so that acommon terminology is used herein.

IDCS Bus Nomenclature

As illustrated in FIG. 3, base station 100 is daisy chained to aplurality of peripheral devices, up to six peripheral devices 310, 320,. . . , 350 and 360 using IDCS bus 150 of this invention via cables 313,323, . . . , 353 and 363 respectively. Base station 100 has a busdispatch 305 that includes the hardware and software subsystems thatsupport IDCS bus 150 of this invention. Bus dispatch 305 is the sole busmaster of the IDCS bus for command and control purposes, i.e., busdispatch 305 initiates all commands that result in data transfer. Forexample, in response to an appropriate command from bus dispatch 305,each peripheral device 310, 320 . . . , 360 on IDCS bus 150 can driveclock and data lines of IDCS bus 150 thereby providing data to busdispatch 305. Each peripheral device, in this embodiment, is responsiblefor indicating to bus dispatch 305 that data transmission from theperipheral device is complete.

Peripheral device 360 is the last peripheral device in the daisy chainand so is referred to as the last peripheral device. All peripheraldevices 310, 320 . . . , 350, except last peripheral device 360, arereferred to as mid-peripheral devices. Cable 363 carries signals fromlast peripheral 360 towards bus dispatch 305 in an upstream directionand signals from bus dispatch 305 towards last peripheral 360 in thedownstream direction.

Bus dispatch 305 of base station 100 controls the operation of IDCS bus150 using commands to the peripheral devices 310 through 360. A commandis a message sent to a peripheral device from bus dispatch 305 directinga peripheral device to perform an operation. A command is sent to aperipheral device when the device is in idle mode, i.e., when theperipheral device is waiting for the next command from bus dispatch 305.

A peripheral device is in a command mode when the peripheral device isresponding to a command received from bus dispatch 305. A peripheraldevice is in a transparent mode when the peripheral device is notlooking for a command from bus dispatch 305. In the transparent mode,any pattern of bits can be transmitted over IDCS bus 150 without anyperipheral device in the transparent mode misinterpreting the pattern ofbits as a command. In other words, in the transparent mode, theperipheral device functions as a signal conduit for peripheral devicesin the downstream and upstream directions.

An address is a unique identification (ID) number for a peripheraldevice on IDCS bus 150. This address is assigned by bus dispatch 305when the peripheral device is added to IDCS bus 150. A participatingperipheral is the peripheral device addressed in a command addressfield. Start of transmission (SOT) and End of transmission (EOT)commands are messages used to indicate the start and end oftransmissions. When the end of transmission message is received by aperipheral device in a command cycle, the message signals the end ofactivity. When the end of transmission signal is sent by a peripheraldevice, the message signals to bus dispatch 305 that the peripheraldevice has finished its portion of the command cycle. A command cycle isthe sequence of events starting with bus dispatch issuing a command andending when bus dispatch or a peripheral device signals EOT.

Basic Features of IDCS Bus 150

FIG. 4 is a more detailed illustration of IDCS bus 150 of this inventioninterconnecting base station 100 and peripheral devices 410, 420, and430. For the number of address bits implemented in this embodiment, IDCSbus 150 supports up to six peripheral devices. However, the features ofthe invention can be adequately described using peripheral devices 410,420 and 430. Moreover, the particular number of peripheral devices onIDCS bus 150 is illustrative only of the principles of this inventionand is not intended to limit the invention to the particular number ofperipheral devices described herein.

Each peripheral device 410, 420 and 430 includes an identical businterface integrated circuit, i.e., Magic Bus Interface Circuit (MBIC)415, 425, and 435, respectively. Thus, a description of the operation ofany one of MBICs 415, 425, and 435 is directly applicable to the otherMBICs.

Base station 100 is connected to bus connector 401 by a firstbi-directional signal line MBDATA, a second bi-directional signal lineMBCLK, and unidirectional interrupt line MBINT. IDCS bus power supplyvoltage MBVCC and signal ground MBGND are also connected to busconnector 401. In this embodiment, power supply line MBVCC carries apower supply voltage of 3.3 volts±10% at 45 Ma maximum. However, in viewof this disclosure, IDCS bus 150 can be implemented using a wide varietyof power supply voltages, because the principles of this invention areindependent of the power supply voltage level used.

Each of peripheral devices 410 to 430 are shown as being identical withrespect to operation on IDCS bus 150. The requirements for support ofIDCS bus 150 are identical for each peripheral device, but the functionsperformed by peripheral devices 410, to 430 are most probably different.For example, peripheral device 410 can be a scanner, peripheral device420 a printer, and peripheral device 430 a non-volatile data storagedevice. Since herein only IDCS bus 150 is of interest, for the purposeof disclosing IDCS bus 150, each peripheral device, unless otherwiseexplicitly noted, is assumed to be identical with respect on operationon IDCS bus 150.

Specifically, each peripheral device 410, 420, 430 has a MBIC 415, 425,435, respectively, coupled to an upstream bus connector 412, 422 and421, respectively, a downstream bus connector 411, 421 and 431,respectively, and a microcontroller 416, 426 and 436, respectively. Inthis embodiment, connectors 401 and 412 form a direct connection 413.Similarly, connectors 411 and 422 form direct connection 423 andconnectors 421 and 423 form direct connection 433. In anotherembodiment, connections 413,423, and 433 could be made by a cable asshown in FIG. 1.

The independence of the bus support interface within a peripheral devicefrom the type of peripheral device means that a low volume peripheraldevice manufacturer is not required to use other than the novel partsdescribed herein. Therefore, the novel structure of this invention canbe widely used without each peripheral device manufacturer incurring thecost of designing a part for interfacing to IDCS bus 150.

MBIC 415 includes a set of upstream buffers 415A, a set of downstreambuffers 415C and a set of peripheral device buffers 415D. Controlcircuit 415B configures these three sets of buffers. In one embodiment,control circuit 415B analyzes the information on lines MBDATA and MBCLK,from upstream buffer circuit 415A and determines whether to pass theinformation through peripheral device 410 to downstream connector 411,or to direct all or part of the information to microcontroller 416through peripheral buffer circuit 415D. Control circuit 415B includes abus state control logic circuit, an interrupt logic circuit, and acommand logic circuit, as explained more completely below.

In another embodiment, MBIC 415 does not include control circuit 415Band the various sets of buffers are controlled by microcontroller 416.The information on IDCS bus 150 is provided to microcontroller 416 andused by microcontroller 416 to configure MBIC 415 appropriately. Aspecification for one embodiment of such a configuration is presented inMicrofiche Appendix A, which is incorporated herein by reference in itsentirety.

Peripheral device 410, in this embodiment, has a local power supply thatprovides a local power supply voltage VCC. MBIC 415 is powered by thevoltage on power supply line MBVCC in IDCS bus 150. Driving MBICs 415,425, and 435 with a common supply voltage assures that the voltagelevels used by buffers within MBICs 415, 425, and 435 are the same. Thevoltage on power supply line MBVCC preferably is not used to power anyother electronics in peripheral devices 410, 420, and 430. However, aperipheral device can sample the voltage level on line MBVCC to controlthe peripheral device's power supply and/or to provide a status for theperipheral device's microcontroller. The amount of current thatperipheral device 410 is allowed to draw from line MBVCC is limited to amaximum of 6 Ma when IDCS bus 150 is fully loaded. This,maximum currentdraw is based on a bus load that includes a passive serial peripheraldevice requiring 5 Ma plus six peripheral devices on IDCS bus 150, eachof which can draw 6 Ma without compromising power to the otherperipheral devices on IDCS bus 150. MBIC 415 is designed to draw 5 Mawhen operating at 14.75 Mhz and 100 μA when in standby mode.

Signals on data line MBDATA, clock line MBCLK and interrupt line MBINTare each buffered by MBICs 415, 425 and 435 at each connection pointalong IDCS bus 150. Signals on power line MBVCC and ground line MBGNDpass through MBICs 415, 425 and 435 unbuffered. In some embodiments,connections 413, 423 and 433 are shielded cables with lines MBDATA andMBGND forming a first twisted pair, and lines MBCLK and MBVCC forming asecond twisted pair. In this embodiment, the maximum length of a cableis about one meter.

Communications between bus dispatch 305 and peripheral devices 410, 420and 430 are called messages. All messages take place within thestructure of serial peripheral interface command cycles, that aredescribed more completely below. In this embodiment, commands aredifferentiated from raw data in that when a command is to betransmitted, the functions of clock line MBCLK and data line MBDATA arereversed, i.e., data line MBDATA carries a clock signal and clock lineMBCLK carries a data signal. Herein, a command refers to a particularsequence of data, that is described more completely below, and isseparate and distinct from raw data which is referred to simply as data.

Commands sent by bus dispatch 305 either configure a MBIC or initiateoperations with a peripheral device. In this embodiment, each commandincludes two bytes. A first byte identifies the peripheral device forwhich the command is intended and a second byte includes an op code thatidentifies the command.

Commands issued by bus dispatch 305 are propagated downstream on IDCSbus 150 to each of MBICs 415, 425, and 435, and are acted upon by eachperipheral device in a manner appropriate for that peripheral device.The particular action taken by a peripheral device depends both upon itsstate and the destination address within the command.

All transfers of information, e.g. data, over IDCS bus 150 are initiatedby bus dispatch 305. If a peripheral device needs to transfer data tobus dispatch 305, peripheral device 410, 420 or 430 must first interruptbus dispatch 305 via a unidirectional interrupt on its respective lineMBINT and then wait for a command from bus dispatch 305 before startingthe data transfer.

During a command cycle, a peripheral device may either receive data,transmit data, or transparently relay data to downstream or upstreamperipheral devices depending on the direction of transfer. All upstreamperipheral devices, e.g. MBICs 415, 425 in peripheral devices 410, 420,must cooperate for a data transfer from a downstream peripheral device,e.g., peripheral device 430, to bus dispatch 305. To ensure cooperation,each MBIC on IDCS bus 150 incorporates a plurality of predefined statesthat are described more completely below. Signal transmissions over IDCSbus 150 are implemented using a serial peripheral interface protocol(SPI), that is also described in greater detail below.

Each of MBICs 415, 425, and 435 in peripheral device 410, 420 and 430 onIDCS bus 150, regardless of whether its address is present in thecommand, monitors commands on IDCS bus 150 to determine the originationand destination of the transaction. Specifically, MBICs 415, 425, 435 ofperipheral devices 410, 420, 430, respectively, recognize when theperipheral device containing the MBIC is being addressed and takeappropriate actions. Conversely, if peripheral device 410, 420, or 430is not being addressed, the MBIC in the peripheral device and theperipheral device itself do not participate in a transaction, except theMBIC acts as a relayer of signals up or down IDCS bus 150. Such aperipheral device operates in a transparent mode until the command isfinished, and then enters the appropriate idle mode, i.e. mid-idle orlast-idle for a mid-peripheral device and a last-peripheral device,respectively.

All command and data transfers between bus dispatch 305 and peripheraldevices 410, 420 and 430 are performed using the SPI protocol. In thisembodiment, the SPI protocol is a half-duplex, synchronous-serial twowire protocol. For a data transfer (FIG. 5A), the clock signal on lineMBCLK and data on line MBDATA are provided simultaneously by the datasource, which is either bus dispatch 305 or one of peripheral devices410, 420 and 430, through its respective MBIC 415, 425 or 435.

Data is transmitted starting with most significant bit B 7! and endingwith least significant bit B 0!. At the data transmission source, datais generated on the rising edge of the clock signal on line MBCLK. Atthe destination or slave, data is sampled on the falling of the clocksignal on line MBCLK. The inactive state of the signals on both linesMBCLK and MBDATA is low. In some embodiments, signal MBCLK has asymmetrical duty cycle clock with a frequency within a frequency rangeof approximately 115 Khz to 14.75 Mhz.

IDCS bus 150 accommodates a single bus master at a time, with all otherbus members being slaves. The clock and data are generated by the solemaster of the bus. In normal IDCS bus operations, the voltage on lineMBDATA does not cycle from a low voltage to a high voltage and back to alow voltage again without a clock rising edge transition occurring onclock line MBCLK. Conversely, commands are transmitted over IDCS bus 150by holding line MBCLK at a high voltage (FIG. 5B) and cycling thevoltage level on line MBDATA to clock the various bits of the command,i.e., the functions of lines MBDATA and MBCLK are reversed from thefunctions for data transmission.

Overview of Bus Dispatch Operation

FIG. 6 is a process diagram 600 of one embodiment of the operation ofbus dispatch 305. The order of sequences 601 to 610 is necessary toassure that MBICs 415, 425, and 435 are in proper states to respond tocommands from bus dispatch 305. Specifically, the reliability of IDCSbus 150 is insured, because sequences 601 to 610 assure that peripheraldevices attached to IDCS bus 150 are initialized and responding properlybefore commands and data are sent onto IDCS bus 150. When bus dispatch305 determines that activity on IDCS bus 150 has remained quiescent fora predetermined time interval, bus dispatch shuts down IDCS bus 150 andturns off the voltage on line MBVCC, i.e., bus dispatch 305 places IDCSbus 150 in a powered-down sleep mode.

In wake-up sequence 601, one of the self-powered peripheral devices onIDCS bus 150 toggles the signal level on line MBINT, e.g., asserts anactive signal on line MBINT for at least 100 nanoseconds (ns). Inresponse to the pulse on line MBINT to bus dispatch 305, bus dispatch305 enters power-on sequence 602. Alternatively, bus dispatch 305 enterspower-on sequence 602 during the power-on process of base station 100.In power-on sequence 602, bus dispatch 305 applies power to IDCS bus 150and then checks whether peripheral devices are attached to bus dispatch305. If peripheral devices are attached, processing transfers frompower-on sequence 602 to bus initialization sequence 620.

Bus initialization sequence 620, in this embodiment, includes bus resetsequence 603, address assign sequence 604, and peripheral configurationsequence 605. In bus reset sequence 603, bus dispatch toggles the IDCSbus power supply voltage MBVCC and then confirms that at least oneperipheral device is attached to bus dispatch 305. If a peripheraldevice is attached, processing transfers from bus reset sequence 603 toaddress assign sequence 604.

In address assign sequence 604, bus dispatch 305 assigns all theperipheral devices on IDCS bus 150 addresses. In this embodiment,peripheral device 410, i.e., the peripheral device closest to busdispatch 305, is assigned identification-number/address 110 (decimal 6),and peripheral device 420, the peripheral device next closest to busdispatch 305, is assigned with identification number 101, and so forth.Sometimes, peripheral device 410 is referred to as the first peripheraldevice on IDCS bus 150.

In this embodiment, only a MBIC has knowledge of its own peripheraldevice's address on IDCS bus 150. Thus, the user, in attachingperipheral devices to IDCS bus 150, does not need to worry about theorder in which the particular peripheral devices are arranged and needsto know nothing concerning the relative location of the peripheraldevice on IDCS bus 150.

Further, bus dispatch 305 can configure IDCS bus 150 without any ofmicrocontrollers 416, 426 and 436 being active. So long as a peripheraldevice's MBIC, e.g. MBIC 415, is functional, a malfunctioningmicrocontroller, e.g. microcontroller 416, does not prevent otherfunctional peripheral devices 420 or 430 downstream from communicatingwith bus dispatch 305 either in bus initialization sequence 620 or insubsequent operation.

After bus dispatch 305 assigns an address to each of peripheral devices410 to 420, bus dispatch 305 transitions to peripheral configurationsequence 605. In peripheral configuration sequence 605, each peripheraldevice informs bus dispatch 305 of its characteristics. The informationprovided typically includes the type (function) of peripheral device,the manufacturer, and the model number. In addition, each peripheraldevice 410 either identifies an existing software device driver,sometimes called a peripheral client, in bus dispatch 305, or is capableof downloading a software device driver to bus dispatch 305. From theperspective of a user, peripheral device 410 is simply attached to basestation 100 and it works.

When bus initialization sequence 620 is completed, i.e., each peripheraldevice has been assigned an address, the peripheral device has beenidentified, and a driver for the peripheral device has been found. MBICs415, 425 and 435 in peripheral devices 410, 420, and 430, respectively,are each in an idle mode and processing transfers to service bussequence 606.

In service bus sequence 606, bus dispatch 305 services interrupts online MBINT and transmits and receives data in response to directionsfrom peripheral clients in base station 100. When there is no activityon IDCS bus 150 and each of peripheral devices 410 to 430 is in the idlemode, the upstream and downstream buffers in each mid-peripheral MBICare configured to pass information downstream from bus dispatch 305.Interrupt signals flow only from peripheral devices 410, 420, and 430 tobus dispatch 305, i.e., upstream only, and so buffers on line MBINT passa signal upstream to bus dispatch 305.

Peripheral devices 410 and 420, as mid-peripheral devices, mustcooperate in transfer of commands and data to any downstream peripheral,and in transfer of commands, data, and interrupt signals upstream to busdispatch 305. Conversely, last peripheral device 430 may not participatein transfer of commands and data downstream, but when a new peripheraldevice is connected to peripheral device 430 via IDCS bus 150,peripheral device 430 must be capable of functioning as a mid-peripheraldevice.

A command sequencer within bus dispatch 305 is responsible for packaginga command into the appropriate sequences and queuing the command in aFIFO circuit within bus dispatch 305 for transmission over IDCS bus 150.In this embodiment, there are four types of command sequences, hardwarecommands, software commands, command Send and command Get. Commands Sendand Get are software commands, but, as explained more completely below,are considered separately because the command sequences for commandsSend and Get are different from the command sequences for the othersoftware commands. Hardware commands are intended for a MBIC in aparticular peripheral device and are not passed along to the peripheraldevice's microcontroller. In the embodiment described below, hardwarecommands are sent as a single command word consisting of two bytes bothof which are read and interpreted by the MBIC in the addressedperipheral device. Hardware commands are sent at the maximum IDCS busspeed, e.g., 14.75 Mbps.

Software commands are commands intended for a peripheral device'smicrocontroller. Software commands also are sent in one two byte commandword with the exception of commands Send and Get, which involve datatransactions and thus follow different sequences. The MBIC, e.g., MBIC415, reads the command word, and if MBIC 415 determines that the commandword is a software command for its microcontroller 416, MBIC 415 passesonly the second byte of the command word that contains a command code tomicrocontroller 416.

Bus dispatch 305 uses command Send to inform a peripheral device thatbus dispatch 305 is about to transmit data to the peripheral device.Command Send may be transmitted over IDCS bus 150 at two differentspeeds. The first byte in the command is intended only for MBICs 415 to435 and so is sent at the maximum bus speed. The second byte is passedto the microcontroller and so the second byte is transmitted at a speedcompatible with the microcontroller as is the subsequent data.

Command Send is followed directly on IDCS bus 150 by the data packet orpackets and then an end of transmission command EOT to the addressedperipheral device that tells the peripheral device that the transactionis completed. Each command Send must be transmitted in this sequence toensure proper gating by MBICs 415, 425 and 435 of lines MBDATA andMBCLK.

Command Get is used by bus dispatch 305 to inform a peripheral device tosend data to bus dispatch 305. The command Get sequence begins with theissuance of command Get by bus dispatch 305. Command Get also may betransmitted over IDCS bus 150 at two different speeds. The first byte inthe command is intended only for MBICs 415 to 435 and so is sent at themaximum bus speed. The second byte is passed to the microcontroller andso the second byte is transmitted at a speed compatible with themicrocontroller.

When the addressed peripheral device receives command Get, theperipheral device responds by sending a start of transmission commandSOT that configures IDCS bus 150 to transmit data from the peripheraldevice to bus dispatch 305. Start of transmission command SOT isfollowed by data packets which are followed by an end of transmissioncommand EOT that tells each MBIC on IDCS bus 150 and bus dispatch 305that the transaction is completed.

End of transmission command EOT, is generated by bus dispatch 305 at theend of each bus transaction. A command logic circuit, which is describedmore completely below, in each of MBICs 415, 425 and 435 continuouslymonitors lines MBDATA and MBCLK for command EOT. Each peripheral device410, 420 and 430 is therefore able to detect the end of all bustransactions.

IDCS bus 150 is fully interrupt driven. Peripheral devices sendinterrupts over line MBINT to get the attention of bus dispatch 305.When bus dispatch 305 senses an interrupt, bus dispatch 305 performs aninterrupt poll, as described more completely below, to the determine thesource and the nature of the interrupt. Interrupts are serviced by busdispatch 305 once the current command cycle is complete. Interruptssignal when a peripheral device requires servicing, e.g., when an actioninitiated by a command is completed, or when data packets are ready fortransmission. Interrupts also indicate when a peripheral device has beenattached or detached from IDCS bus 150 and when an IDCS bus 150 erroroccurred.

Bus dispatch 305 adheres to a fairness protocol which insures that allperipheral devices receive equal priority on IDCS bus 150. Bus dispatch305, in one embodiment, implements the fairness protocol using afirst-in-first-out memory (FIFO) that is divided into two slots, i.e., alow priority slot for commands, and a high priority slot for interrupts.Commands are processed in the order in which the commands are receivedin the low priority slot, but a command is not handled until interruptsare serviced. Upon completion of each command cycle, bus dispatch 305first checks the high priority slot for interrupts received. If the highpriority slot is empty, bus dispatch 305 determines whether interruptline MBINT is high indicating that an interrupt is on IDCS bus 150. Ifinterrupt line MBINT is high, bus dispatch 305 performs anInterrupt-Poll sequence. Conversely, bus dispatch 305 processes theoldest command in the low priority slot. Interrupt polling, as describedmore completely below, is conducted by bus dispatch 305 in a round robinfashion such that no peripheral device has priority for interruptservicing.

Thus, interrupts from peripheral devices are serviced between commandcycles as they occur. If an interrupt and a command are receivedsimultaneously by bus dispatch 305, the interrupt is serviced first. Ifreal-time mode is enabled, interrupts are serviced at regular intervalsat a latency time specified by the peripheral device. Bus dispatch 305sets the command cycle length for IDCS bus 150 based on the lowestlatency interrupt response time of the peripheral devices on IDCS bus150.

Connection of a Peripheral Device

If only peripheral devices 410 and 420 are on IDCS bus 150, MBIC 425shuts off signal transmission on lines MBDATA and MBCLK to bus connector421 because peripheral device 410 is a mid-peripheral device andperipheral device 420 is the last-peripheral device on IDCS bus 150, inthis example. With signal transmission to bus connector 421 shut off byMBIC 425, peripheral device 430 can be connected to bus connector 421under one of three conditions.

The first condition is when base station 100 is configured so that thepower supply voltage to IDCS bus 150 is turned off, i.e., IDCS bus 150is asleep. In this case, the peripheral device is initialized in businitialization 620, as described above.

The second condition is when peripheral devices 410 and 420 are in theidle mode and the third condition is when active communications areoccurring on IDCS bus 150. In both of those conditions, bus dispatch 305is in service bus sequence 606.

When peripheral device 430 is connected at the end of the daisy chain tobus connector 421, MBIC 435 is isolated from the signals onbi-directional lines MBDATA and MBCLK. The act of connecting peripheraldevice 430 to bus connector 421 supplies the bus power from connector421 to MBIC 435 which in turn provides a signal indicating that buspower is available to microcontroller 436.

The act of docking peripheral device 430 to peripheral device 420results in an interrupt being sent to bus dispatch 305 if IDCS bus powersupply voltage MBVCC is on. Note that herein the line carrying the buspower supply voltage and the bus power supply voltage have the samereference numeral for convenience. This convention is also used forother lines and terminals that are described herein. MBIC 435 inperipheral device 430 configures peripheral device 430 so thatdownstream connector 431 is terminated. Thus, signals are not radiatedfrom connector 431 in the process described below.

If peripheral devices 410 and 420 are in the idle mode, bus dispatch305, upon receipt of the interrupt signal from peripheral device 430,performs an Interrupt-Poll sequence within service bus sequence 606.When bus dispatch 305 determines that neither peripheral device 410 norperipheral device 420 generated the interrupt, processing transfers toperipheral attachment sequence 609.

In peripheral attachment sequence 609, bus dispatch 305 configuresperipheral device 420 as a mid-peripheral device. Specifically, busdispatch 305 sends command Assign Mid-Peripheral to last addressedperipheral device 420 on IDCS bus 150 and so the last addressedperipheral device functions as a mid peripheral. As explained above, asa mid peripheral device 420, MBIC 425 enables the downstream signallines to allow bus dispatch 305 to communicate with newly attachedperipheral 430. Bus dispatch 305 then transfers processing to addressassign sequence 604. Peripheral device 430 is assigned an address insequence 604 and then peripheral configuration sequence 605 configuresbus dispatch 305 to support peripheral device 430 on IDCS bus 150.

If active communications are occurring on bus 150 when the interruptsignal is received from peripheral device 430, bus dispatch 305, at anappropriate later time, performs the interrupt poll sequence, and takesperipheral device 430 through the peripheral attachment sequence 609 inthe same matter as just described when peripheral devices 410 and 420were idle.

Disconnection of a Peripheral Device

Any one of peripheral devices 410, 420, 430, can be disconnected fromIDCS bus 150 at any time without causing a catastrophic failure of IDCSbus 150. Thus, any peripheral device can be removed when IDCS bus 150 isin any one of the three sequences described above for connectingperipheral device 430.

When a peripheral device is removed during a power down or sleep period,all peripheral devices connected to IDCS bus 150 are re-registered whenbus dispatch 305 powers up IDCS bus 150 in sequence 602 and thenperforms bus initialization sequence 620. The disconnection of aperipheral device that occurred at power down or during the sleep periodis detected during the re-registration process.

If all peripheral devices 410, 420 and 430 are in the idle mode when thedisconnection occurs, the peripheral device immediately upstream fromthe disconnection is notified by the signal level on line MBINT and inturn sends an interrupt to bus dispatch 305. Bus dispatch 305, inresponse to the interrupt, performs an Interrupt-Poll sequence. Since aperipheral device has not generated the interrupt, an interrupt-pollerror occurs and bus dispatch 305 transitions through peripheraldetachment sequence 608 to bus initialization sequence 620 whichreconfigures IDCS bus 150 in view of the disconnection.

If data is being transmitted on IDCS bus 150 when disconnection of aperipheral device involved in the transmission occurs, a communicationtime-out occurs and bus dispatch 305 cancels the transaction. Busdispatch 305, in response to the interrupt generated by thedisconnection, reconfigures IDCS bus 150 in view of the disconnection bytransitioning through peripheral detachment sequence 608 to businitialization sequence 620, as described above. Thus, disconnection ofa peripheral device from IDCS bus 150 requires no action by the user toreconfigure or terminate the bus. All of these actions are performedautomatically.

During a normal power down of IDCS bus 150 by bus dispatch 305, busdispatch 305 notifies each peripheral device 410, 420, 430 of the powershut down in power warn sequence 607 and MBICs 415, 425, 435 establishsafe, non-contentious bus conditions. Similarly, if IDCS bus powersupply voltage MBVCC starts to fall into a range that can not supportbus operations, bus dispatch 305 enters power warn sequence 607 tonotify each attached peripheral device of the pending power down. Uponcompletion of power warn sequence 607, IDCS bus 150 enters a busdisabled state 610. For an unexpected power down of IDCS bus 150, eachmicrocontroller 416, 426, 436 monitors the power supply voltage to therespective MBIC 415, 425, 435, and shuts down the peripheral device asappropriate.

Command Structure

In this embodiment, commands are transmitted over IDCS bus 150 in two8-bit (byte) packets (FIG. 5C). Each two-byte command 510 containsthirteen bits of data, plus a parity bit. First command byte 510Acontains control bits plus the address of the peripheral device forwhich the command is destined. Second command byte 510B contains thecommand code itself, plus a parity bit.

In first command byte 510A the first two bits are command detectionbits. The command detection bits are set to logic one to identify firstcommand byte 510A as part of a command to a MBIC. The command detectionbits are used to resynchronize the MBIC, as described below.

Third bit REV2 in first command byte 510A is a revision bit. This bit isa reserved bit and is used to indicate the revision of the SPI protocol.For revision one of the SPI protocol, bit REV2 must be a logic zero, forexample.

Fourth bit MBI of byte 510A is a bus-interface-circuit bit. Ifbus-interface-circuit bit MBI is set to a value of a logic zero, a MBICallows the contents of second command byte 510B to pass through to themicrocontroller. Conversely, when bus-interface-circuit bit MBI is setto a value of logic one, the command is intended only for a MBIC and sosecond command byte 510B is not passed through to the associatedmicrocontroller.

Bits five through seven i.e., bits A2-A0 of first command byte 510A,contain the address of the peripheral device for which the command isintended. The address starts with the most significant bit A2 in bitfive and the least significant bit A0 is in bit seven of first commandbyte 510A. The eighth bit of first command byte 510A is reserved in thisembodiment and should be a logic zero. However, the eighth bit could beused as a fourth address bit and thereby expand the capacity of IDCS bus150.

In this embodiment, peripheral device addresses are 3-bit codes thatuniquely identify each currently attached peripheral device anddesignate relative downstream/upstream positions of peripheral devicesto each other. Peripheral devices 410, 420 and 430 are each assigned aunique peripheral address by bus dispatch 305 when first attached toIDCS bus 150 in bus initialization sequence 620. This address remainsunchanged until either peripheral device(s) 410, 420 and/or 430 aredisconnected from bus IDCS 150 or reset. In one embodiment, addressesare assigned as given in Table I.

                  TABLE I                                                         ______________________________________                                        ADDRESS ASSIGNMENTS                                                           ______________________________________                                        Address 7:     designates a message broadcast to                                             all peripheral devices by bus                                                 dispatch 305.                                                  Address N:     (1 ≦ N < 7) designates the (7-N)th                                     peripheral device on IDCS bus 150.                             Address 0:     reserved                                                       ______________________________________                                    

In sum, first command byte 510A contains seven bits of data that (a)identify a command data structure, (b) indicate the revision level ofthe command, (c) instruct whether the following byte is intended for amicrocontroller or only a MBIC, and (d) also identify the address of theperipheral device for which command 510 is intended.

The first five bits C 4! to C 0! of second command byte 510B are commandcode bits that contain the command operation code (op code) itself (Seealso Table IV). Sixth bit PAR of second command byte 510B is a paritybit that is used to guarantee the integrity of the information incommand bytes 510A and 510B. In this embodiment, even parity is used todetermine whether to set bit PAR. Even parity signifies that parity bitPAR is set to a logic value such that the sum of the total number ofbits having a value of logic one is an even number. For example, if thepreceding thirteen bits of the command bytes 510A, 510B have an oddnumber of logic one bits, parity bit PAR is set by bus dispatch 305 tologic one, so as to make the total number of logic one bits even.Conversely, if the first thirteen bits of the command bytes 510A, 510Bhave an even number of logic one bits, then parity bit PAR is set tologic zero.

The last two bits of second command byte 510B must always be logic zero.A MBIC always checks the parity of a received command with parity bitPAR at the end of every command to determine whether the command hasbeen received without transmission errors. If the MBIC detects a parityerror, the MBIC immediately terminates any further communications, sendsan interrupt to bus dispatch 305 and issues a reset signal to themicrocontroller. Specifically, the MBIC and the associatedmicrocontroller return to same state as when the peripheral devicecontaining the MBIC and microcontroller was first added to IDCS bus 150and an interrupt is sent by the MBIC to bus dispatch 305. When busdispatch 305 detects the interrupt and determines that the cause of theinterrupt was an error, bus dispatch 305 resets IDCS 150 and initiatesbus initialization sequence 620.

Bus Commands

In this embodiment, commands are subdivided into software commands andhardware commands. Software commands are passed by a MBIC to themicrocontroller to which it is connected, e.g., from MBIC 415 tomicrocontroller 416. In this embodiment, the software commands are givenin Table II.

                  TABLE II                                                        ______________________________________                                        SOFTWARE COMMANDS                                                             ______________________________________                                                   1. Power-Warning                                                              2. Soft-Reset                                                                 3. Verify                                                                     4. Send-xxx                                                                   5. Get-xxx                                                                    6. Reserved                                                        ______________________________________                                    

A MBIC passes only the second byte of the software command tomicrocontroller 416 of peripheral device 410. Only two types of softwarecommands, Send-xxx and Get-xxx, involve data transactions in addition tothe two command bytes. Herein, -xxx is used in commands Send and Get toindicate that more than one command is envisioned. Command Send-xxxinvolves a transfer of data from base station 100 to a peripheraldevice, while command Get-xxx involves the transfer of data from aperipheral device to base station 100.

In this embodiment, hardware commands intended only for a MBIC are givenin Table III.

                  TABLE III                                                       ______________________________________                                        HARDWARE COMMANDS                                                             ______________________________________                                        1. Clear-Error-Flag                                                           2. Assign Address                                                             3. Assign Mid/Last-Peripheral                                                 4. Error-Poll                                                                 5. Interrupt-Poll                                                             6. Set/Clear-Hardware Reset                                                   7. Set/Clear-Peripheral Power-on                                              8. Start/End-of-Data-Transmission (SOT/EOT)                                   ______________________________________                                    

Hardware commands are either addressed to a particular MBIC, oraddressed globally, e.g., broadcast to all MBICs 415, 425 and 435 onIDCS bus 150.

A command cycle begins with the issuance of a command by bus dispatch305. The command defines the peripheral device or peripheral devicesthat must respond(s) and the action to be taken by the peripheral deviceor devices. Here, a peripheral device should be understood to mean theMBIC in the peripheral device if the command is a hardware command andthe microcontroller in the peripheral device if the command is asoftware command. In this embodiment, as explained above, first commandbyte 510A contains the address of the destination peripheral and secondcommand byte 510B a command operation code (op code). The op codedefines the particular action to be performed.

Table IV lists the assignment of various commands to the five bitcommand op-code field for one embodiment of this invention.

                  TABLE IV                                                        ______________________________________                                        Op-Code     Command            Global                                         ______________________________________                                        00h         Power-Warning      No                                             01h         Soft-Reset         No                                             02h         Verify             No                                             03h         IRQ-Get            No                                             04h-06h     Get-xxx            No                                             07h-0Ah     Send-xxx           No                                             0Bh         Request ID         No                                             0Ch         Get Peripheral Info                                                                              No                                             0Dh         Get Driver         No                                             0Eh-13h     Reserved           No                                             14h         Clear Error Flag   No                                             15h         Assign Address     No                                             16h         Assign Mid-Peripheral                                                                            No                                             17h         Assign Last-Peripheral                                                                           No                                             18h         Error-Poll         Yes                                            19h         Interrupt-Poll (IRQ-Poll)                                                                        Yes                                            1Ah         Set-Hardware-Reset Yes                                            1Bh         Clear-Hardware-Reset                                                                             Yes                                            1Ch         Set-Peripheral-Power-On                                                                          Yes                                            1Dh         Clear-Peripheral-Power-On                                                                        Yes                                            1Eh         Start-of-Transmission (SOT)                                                                      No                                             1Fh         End-of-Transmission (EOT)                                                                        No                                             ______________________________________                                    

The first twenty op-code values, i.e., 00h through 13h, are reserved forsoftware commands and the next twelve op-code values, i.e., 14h through1Fh, are reserved for hardware commands. The op-code values are listedin the first column of Table IV with the corresponding command typelisted in the second column of the table.

The third column of table IV indicates whether the command can beaddressed globally to all peripheral devices 410, 420 and 430 on IDCSbus 150, or whether the command is intended only for a specificperipheral device identified in the address field of first command byte510A. Both software commands Get-xxx and Send-xxx are each assigned fourop-code values, 03h to 06h and 07h to 0Ah, respectively. Softwarecommands Get-xxx include command IRQ-Get. Reserved commands,corresponding to op-code values 0Eh to 13h, are ignored by a MBIC, butare passed on by the MBIC to the addressed microcontroller if bit REV2and bit MBI are both set to a logic zero.

Each of the various commands is described briefly followed by a detaileddescription of one specific implementation of a MBIC. The various statesof a state machine within a MBIC, that are referred to in the followingdescription, are discussed in greater detail below. Briefly, in thisembodiment, a MBIC can be in any one of a plurality of states. Thestates include: power-on, no-address, mid-idle, last-idle, pre-pass-up,pass-up, pre-get, get, post-get, and send. Further, any one of MBICs415, 425, and 435 can be in a state different from the state of theother two MBICs at any instant in time.

Command Power-Warning is transmitted to the peripheral device addressedin the first byte of the command. Command Power-Warning notifies theperipheral device microcontroller that IDCS bus power supply voltageMBVCC is about to fall out of the specified operating range, i.e., theIDCS bus power supply voltage is about to shut down. In response tocommand Power-Warning, the microcontroller assumes a disconnected state,and ignores all subsequent activity on IDCS bus 150.

Software command Soft-Reset is transmitted to a microcontroller of aparticular peripheral device, e.g., microcontroller 416 in peripheraldevice 410. Command Soft-Reset instructs the microcontroller to resetitself to a known state, typically, state No-Address. When the reset iscomplete, an interrupt is sent to bus dispatch 305.

Command Verify is addressed to a particular peripheral device, e.g.,peripheral device 410, and indicates to microcontroller 416 thatperipheral device 410 should perform a self diagnostic routine andgenerate an interrupt to bus dispatch 305 when the self diagnosticroutine is completed. Bus dispatch 305 sends out a commandInterrupt-Poll (IRQ-Poll) as described more completely below, inresponse to the interrupt sent by microcontroller 416. When bus dispatch305 determines that microcontroller 416 issued the interrupt, busdispatch 305 issues command IRQ-Get. In response to command IRQ-Get, theaddressed peripheral device transmits a two-byte packet, in thisembodiment, to bus dispatch 305. The specific information in the packetis determined by the driver for the peripheral device, because busdispatch 305 simply passes the information in the packet to the driver.After bus dispatch 305 has received the response to command IRQ-Get, busdispatch 305 sends an end of transmission command EOT.

As discussed above, command Get-xxx requests information from aparticular peripheral device while command Send-xxx sends information toa particular peripheral device or devices. Both commands Get-xxx andSend-xxx rely on the presence of adequate data buffering resources atthe receiving end, i.e., at a receiving device or at bus dispatch 305.Bus dispatch 305 transmits an end of transmission command EOT at the endof the data stream in either case.

Software commands Request ID, Get Peripheral Info, and Get Driver arestatus commands. These commands inform the addressed microcontroller ofthe information that is to be transmitted in response to the nextcommand get that is addressed to that microcontroller.

Hardware command Clear Error Flag clears an error flag in a MBIC that isset upon detection of a parity error. In response to command Clear ErrorFlag, the addressed MBIC clears the error flag. Hardware commandAssign-Address is recognized by the MBIC closest to base station 100that has not been assigned an address. When a new peripheral device isconnected to IDCS bus 150, the peripheral device must complete the powerup sequence within a certain time period, e.g. 100 msec, afterconnection to IDCS bus 150 so that the MBIC in the peripheral device isready to receive command Assign-Address from bus dispatch 305. The MBICin the newly attached peripheral device takes the address in the firstbyte of this command as the identify (ID) address and assumes normaloperation in a Last-Idle state.

Command Assign Mid-Peripheral is specifically addressed to a particularbus interface circuit, e.g. in this embodiment, either MBIC 415 or 425,and causes one of MBIC 415 or 425 to enter a state Mid-Idle, i.e.peripheral device 410 or 420 functions as a mid-peripheral device.

Command Assign Last-Peripheral directs a specific MBIC to re-configureitself as the last peripheral device. This command can be used by busdispatch 305 to reconfigure IDCS bus 150 when a peripheral device isremoved from IDCS bus 150.

Command Error-Poll is sent to a specific peripheral device, e.g.peripheral device 420, and allows bus dispatch 305 to determine whetherMBIC 425 detected a parity error in transmission of a command toperipheral device 420. Command Error-Poll is identical with commandInterrupt-Poll, with the exception that when peripheral device 420 iserror polled, MBIC 425 disables both peripheral device 420 anddownstream interrupt channels and so interrupt line MBINT is driven onlyby MBIC 425. Peripheral device(s) upstream or downstream from device420, i.e. devices 410 or 430, respectively, receive the commandError-Poll and behave as if they received command Interrupt-Poll.

Command Interrupt-Poll (IRQ-Poll) allows bus dispatch 305 to determinewhich peripheral device is the source of an interrupt. Bus dispatch 305sequentially transmits command IRQ-Poll to each peripheral device onIDCS bus 150. When command Interrupt-Poll is sent to a particularperipheral device, e.g. peripheral device 420, MBIC 425 enables itsperipheral device interrupt line, but disables the downstream interruptlines. Peripheral devices, upstream from device 420, e.g., peripheraldevice 410, disable the respective peripheral device interrupt lines andenable the respective downstream interrupt line. Peripheral devicesdownstream, e.g. device 430, from polled peripheral device 420, enableboth their respective peripheral and downstream interrupt channels.

Thus, if an interrupt is detected when peripheral device 420 is polledand peripheral device 420 is connected to IDCS bus 150, the onlypossible source of the interrupt is peripheral device 420 because MBIC425 disabled the downstream interrupt line and MBIC 415 disabled theperipheral interrupt line. Consequently, if either peripheral device 420or MBIC 425 generated the interrupt, the interrupt signal is active atbus dispatch 305 after bus dispatch 305 transmits command IRQ-Poll toMBIC 425. After receiving command IRQ-Poll, peripheral device 420responds by removing the interrupt from line MBINT, if peripheral device420 was the source of the interrupt. If an interrupt is not detectedwhen peripheral device 420 is polled, the polling continues until theperipheral device that generated the interrupt is detected.

If command IRQ-Poll is sent with the address field set to a globaladdress, i.e., an address of seven, interrupts are enabled for allperipheral devices 410, 420 and 430. If command IRQ-Poll is set with anaddress of zero, peripheral device generated interrupts are disabled,but the downstream interrupt lines on all peripheral devices 410, 420and 430 are enabled, i.e. devices 410, 420 and 430 are able to propagateinterrupts in an upstream direction.

Command Set Hardware Reset and command Clear Hardware Reset respectivelyallow bus dispatch 305 to reset the microcontroller in a particularperipheral device and to clear a reset signal to a particular peripheraldevice. For example, when a MBIC detects a error, the MBIC generates areset signal to the microcontroller. Consequently, bus dispatch 305 canuse command Clear Hardware Reset to remove the reset signal to theperipheral device. In response to command Set Hardware Reset, the MBICand the microcontroller assume the power-on state, which is describedmore completely below.

Commands Set Peripheral Power-on and Clear Peripheral Power-on are partof the IDCS bus power protocol that is explained more completely below.Bus dispatch 305 issues command Set Peripheral Power-on and ClearPeripheral Power-on to power up and power down, respectively, aperipheral device containing the addressed MBIC respectively. In thisembodiment, the support for the two commands is optional.

Hardware Start-of-Transmission command SOT and End-of-Transmissioncommand EOT are used by both dispatch 305 and peripheral devices 410,420, 430 as part of the IDCS bus protocol, to identify the beginning andthe end, respectively, of a data transmission.

In this embodiment, command SOT has an address of seven and bit MBI set.Similarly, command EOT also has bit MBI set. However, the address ofcommand EOT varies depending on whether bus dispatch 305 or a peripheraldevice issues command EOT.

When command EOT is issued by bus dispatch 305, command byte 510A hasthe address bits set to the address of the peripheral device involved inthe data transaction. Conversely, when command EOT is issued by aperipheral device command EOT has the address bits set to seven. Bit MBIis set to guarantee that commands SOT and EOT are never passed throughto a microcontroller. An address of seven in either a command SOT orcommand EOT prevents generation of peripheral command EOT by any ofperipheral devices 410, 420 and 430. Bus dispatch 305 must send acommand EOT with a particular peripheral device's address to assert thatperipheral device's end of transmission signal.

A First Detailed Embodiment of a MBIC

Prior to considering the operation of each MBIC in further detail, anembodiment MBIC 700 (FIG. 7A) of MBICs 415, 425, and 435 is considered.Line MBDATA (FIG. 4) is coupled to terminal UPMBDATA on upstream side700A (FIG. 7A) of MBIC 700 and to terminal DNMBDATA on down stream side700B. Herein, for convenience signal lines between bus dispatch 305 andthe first peripheral device and signal lines between peripheral devicesare all referred to as lines MBDATA, MBCLK and MBINT and a similarconvention applies to the bus power supply and ground lines. Theparticular location of a line in the bus will be apparent from thecontext of the disclosure.

Any signal on terminal UPMBDATA drives buffer 706 which in turn drivesline UPDATA. Any signal on line UPDATA drives a first input line ofmultiplexer 718, a first input line of multiplexer 723, a first inputline of multiplexer 735 and a first input line of multiplexer 756. Asecond input line of multiplexer 718 is grounded. Control line 719 ofmultiplexer 718 is driven by bus state control logic circuit 760. Theoutput line of multiplexer 718 is connected to the input terminal ofthree-state buffer 717, which has an output terminal connected toterminal DNMBDATA. Control line 720 to three-state buffer 717 is drivenby bus state control logic circuit 760.

Any signal on terminal DNMBDATA drives buffer 716 which in turn drivesline DNDATA. Any signal on line DNDATA drives a first input line ofmultiplexer 708 and a first input line of multiplexer 756. Control line709 of multiplexer 708 is driven by bus state control logic circuit 760.The output line of multiplexer 708 is connected to an input terminal athree-state buffer 707 which in turn has an output terminal connected toterminal UPMBDATA. Control line 710 to three-state buffer 707 is drivenby bus state control logic circuit 760.

Line MBCLK (FIG. 4) is coupled to terminal UPMBCLK on upstream side 700Aof MBIC 700 (FIG. 7A) and to terminal DNMBCLK on down stream side 700B.Any signal on terminal UPMBCLK drives buffer 701 which in turn drivesline UPCLK. Any signal on line UPCLK drives a first input line ofmultiplexer 713, a second input line of multiplexer 723, a second inputline of multiplexer 735, and a first input line of multiplexer 755. Asecond input line of multiplexer 713, a third input line of multiplexer723, and a third input line of multiplexer 735 are grounded. Controllines 714, 724, and 736 of multiplexers 713, 723, and 735, respectivelyare driven by bus state control logic circuit 760. A signal on theoutput line of multiplexer 713 drives a three-state buffer 712, which inturn drives terminal DNMBCLK. Control line 715 to three-state buffer 712is driven by bus state control logic circuit 760.

Any signal on terminal DNMBCLK drives buffer 711 which in turn drivesline DNCLK. The signal on line DNCLK drives a first input line ofmultiplexer 703 and a second input line of multiplexer 755. Control line704 of multiplexer 703 is driven by bus state control logic circuit 760.Any signal on the output line of multiplexer 703 drives a three-statebuffer 702 which in turn drives terminal UPMBCLK. Control line 705 tothree-state buffer 702 is driven by bus state control logic circuit 760.

Peripheral device data line terminal PMBDATA to and from a peripheraldevice is connected to an input terminal of buffer 721, which in turn isconnected to line PDATA. Any signal on line PDATA drives a second inputterminal of multiplexer 703, a second input terminal of multiplexer 708,and a third input terminal of multiplexer 755. Line SEL from bus statecontrol logic circuit 760 carries the signal that controls the outputsignal on line CMDDATA from multiplexer 755 to command logic circuit 780and the output signal on line/CMDCLK from multiplexer 756 to commandlogic circuit 780.

The output signal from multiplexer 723 drives three-state buffer 722which in turn drives peripheral device data line terminal PMBDATA.Control line 725 to three-state buffer 722 is driven by bus statecontrol logic circuit 760.

A signal on peripheral device clock line terminal PMBCLK drives buffer731, which in turn drives a first input terminal of exclusive OR gate733. A signal on peripheral device I/O line terminal PSIOP drives buffer741, which in turn drives a second input terminal of exclusive OR gate733. The output signal from exclusive OR gate 733 drives line PCLK whichin turn drives a third input line of multiplexer 703, a third input lineof multiplexer 708, and a third input line of multiplexer 756.

The output signal from multiplexer 735, which is selected by the signalon line 736 from bus state control logic circuit 760, drives a firstinput terminal of exclusive OR gate 734. A second input terminal ofexclusive OR gate 734 is driven by the signal from buffer 741. Theoutput signal of exclusive OR gate 734 drives three-state buffer 732which in turn drives peripheral device clock line terminal PMBCLK undercontrol of the signal on line 737 from bus state control logic circuit760.

Hence, when the input signal on terminal PSIOP is asserted, exclusive ORgate 733 inverts the signal on terminal PMBCLK, while exclusive OR gate734 inverts the signal from multiplexer 735 to terminal PMBCLK. Thus,when the signal on terminal PSIOP is asserted and the microcontroller isthe master of the bus, the signal on terminal PMBCLK is inverted beforebeing presented on terminal UPMBCLK to upstream peripheral devices.Conversely, when the signal on terminal PSIOP is asserted and the signalon terminal UPMBCLK is the bus clock, the signal on terminal UPMBCLK isinverted before being presented on terminal PMBCLK to themicrocontroller.

Thus, terminal PSIOP allows a system designer to tailor MBIC 700 tomatch the type of serial port in the microcontroller. When the signal onterminal SIOP is asserted, MBIC 700 can interface with microcontrollerscontaining serial I/O ports. When the signal on terminal PSIOP isnegated, MBIC 700 can interface with microcontrollers containing serialperipheral interface modules compatible with the SPI protocol of thisinvention.

Line MBINT (FIG. 4) is coupled to terminal UPINTOUT on upstream side700A of MBIC 700 (FIG. 7A) and to downstream interrupt in terminalDNINTIN, hereinafter terminal DNINTIN, on down stream side 700B of MBIC700. The signal on upstream interrupt out terminal UPINTOUT,hereinafter, terminal UPINTOUT, is a function of the signals ondownstream interrupt terminal DNINTIN and peripheral device interrupt interminal PINTIN. Downstream interrupt in terminal DNINTIN drives aninput line to interrupt logic circuit 770. An output line from interruptlogic circuit 770 is connected to an input terminal of buffer 742. Anoutput terminal of buffer 742 is connected to upstream interrupt lineterminal UPINTOUT.

A signal on peripheral power-on line terminal/PON, which is active low,drives inverting buffer 751 which in turn drives power-on line PON. Thepower-on signal on line PON is an input signal to bus state controllogic circuit 760, interrupt logic circuit 770, and command logiccircuit 780. The signal on peripheral power-on line PON is used toprovide a power-on reset signal for MBIC 700. When signal PON isasserted, internal MBIC registers are initialized to state power-on.Signal PON should be asserted by the microcontroller for a minimum of100 microseconds after the power supply voltage on line MBVCC to MBIC700 is asserted.

Peripheral interrupt line terminal PINTIN is connected to interruptlogic circuit 770 and to a drain of field effect transistor (FET) 752.The source of FET 752 is grounded. Terminal SWAP, which is driven by theperipheral device microcontroller, drives an input line of command logiccircuit 780 and a drain of FET 753. The source of FET 753 is grounded. Apulse is generated by the microcontroller on line SWAP prior to sendingeither command SOT or command EOT so that the function of signals onterminals PMBDATA and PMBCLK are swapped. A power down signal from aperipheral device on peripheral device power down line terminal PPWRDWNdrives buffer 754 which in turn drives the gates of FETs 752 and 753 andan input line of command logic circuit 780.

The input signal on line PPWRDWN, when asserted, drives the signals onterminals PMBCLK, PMBDATA, PINTIN, SWAP, PRESET, TOMBIC, and PEOT to alogic zero value. Signal PPWRDWN is asserted by external logic when thatlogic detects that the peripheral device's power supply voltage level isno longer adequate to support operations. Preferably, the signal on linePPWRDWN is qualified with the signal on line MBVCC so that signalPPWRDWN is not asserted when the power-on line MBVCC is turned off.

Command logic circuit 780 has a first output line connected tothree-state buffer 743, a second output line connected to three-statebuffer 744, a third output line connected to buffer 745 and a fourthoutput line connected to buffer 746. The signal on line 747 from commandlogic circuit 780 drives the control terminal of three-state buffers 743and 744. The signal from three-state buffer 743 drives terminal PEOT tothe peripheral device while the signal from three-state buffer 744drives peripheral device reset line terminal PRESET. The signal frombuffer 745 drives peripheral device power-on line terminal PPWRON andthe signal from buffer 746 drives terminal TOMBIC.

The signal on terminal PEOT is pulsed when command logic circuit 780decodes command EOT to its peripheral device. Since the signal onterminal PEOT is pulsed, the microcontroller should be edge sensitive.The signal on terminal PEOT is also taken low when the signal on linePPWRDWN is asserted.

The signal on terminal PRESET is the reset signal for themicrocontroller. Preferably, terminal PRESET drives an open collectorinvertor that is in turn connected to the microcontroller's resetterminal. MBIC 700 always checks parity bit PAR at the end of everycommand to determine whether the command has been successfully receivedby MBIC 700, i.e., received error-free. If MBIC 700 detects a parityerror, MBIC 700 immediately terminates any further communications byasserting terminal PRESET, and by executing a branch back to a statepower-on, that is described more completely below.

The signal on terminal PPWRON is an optional power-on signal to thepower supply of the peripheral device that instructs the power supply topower up and power down. In one embodiment, if the signal on line PPWRONis used, the signal drives a first input terminal of an open collectorNAND gate with a second input terminal driven by power supply line VCCof the peripheral device. The output signal of the NAND gate is pulledup to the voltage of a continuous source of power through a resistor andis connected to terminal PPWRDWN. Another embodiment is illustrated inFIG. 14.

The signal on terminal TOMBIC is an optional control signal to allow useof a five volt microcontroller in place of the normal three voltmicrocontroller. The signal on terminal TOMBIC controls the direction ofan external buffer that level translates the signals from the five voltmicrocontroller to three volts signals required by MBIC 700. Theexternal buffer must be able to accept five volt level signals on oneside and three volt level signals on the other side without incurringlatchup.

The signal on terminal/TRIBUFF is a test signal to generate test vectorsand in normal operation is driven with a logic one level. When thesignal on terminal/TRIBUFF is asserted, the signal is used to tri-statebuffers 702, 707, 712, 717, 722, and 732.

Thus, each MBIC 700 has three sets of signal lines. The first set ofsignals on terminals UPMBCLK, UPMBDATA, and UPINTOUT, is for connectingupstream, the second set of signals on terminals PMBCLK, PMBDATA, andPINTIN, is for connecting internally to a microcontroller and the thirdset of signals on terminals DNMBCLK, DNMBDATA, DNINTIN, is forconnecting to the downstream peripheral device(s) if any. All three setsof the signal lines are connected to and are controlled by MBIC 700.Further, MBIC 700 swaps the signals on the various clock and data linesas necessary for the transmission of commands and data.

A Second Embodiment of a MBIC

Another embodiment MBIC 700-1 of MBICs 415, 425, and 435 is presented inFIG. 7B. In MBICs 700 and 700-1, identical parts have the same referencenumeral. Since MBIC 700-1 is similar to MBIC 700, herein only thefeatures that are different in MBIC 700-1 from those described above forMBIC 700 are considered.

Multiplexers 723 and 735 of MBIC 700 have been replaced in MBIC 700-1with multiplexer and synchronization circuits 723-1 and 735-1,respectively. Specifically, a synchronization circuit, that is describedmore completely below, is inserted in the output line of multiplexer 723to obtain multiplexer and synchronization circuit 723-1 and in theoutput line of multiplexer 735 to obtain multiplexer and synchronizationcircuit 735-1. The output signal from exclusive OR gate 757 is providedto both of the synchronization circuits. A first input terminal ofexclusive OR gate 757 is driven by the output signal of buffer 758,which in turn is driven by the signal on line OSC. A second inputterminal of exclusive 0R gate 757 is driven by the output signal ofbuffer 759, which in turn is driven by the signal on line OSCEDGSEL.

Signal OSCEDGSEL is used to select an edge of a signal on line OSC towhich the signals on lines PMBCLK and PMBDATA to the microcontroller aresynchronized. Thus, the signal on line OSC is a clock that is used tosynchronize signals PMBCLK and PMBDATA to the signal on line OSC. Thesynchronization of these signals is important for some microcontrollerssuch as the microcontroller sold by Motorola Corp. of Phoenix, Ariz.85036 under Model No. MC68HC05. After power up, a transition from alogic zero to a logic one on line OSC enables each of thesynchronization circuits. Hence, connecting line OSC to ground disablesthe synchronization circuits and so signals PMBCLK and PMBDATA are notsynchronized to signal OSC, i.e., the function of multiplexers 723 and735 is reproduced in MBIC 700-1.

Terminal UPMBCLKR is connected to a drain of field effect FET 790. Thesource of FET 790 is grounded. Bus state control logic circuit 760drives gate of FET 790. Control logic circuit 760 drives the gate of FET790 in states Pre-Get and Pre-Pass-Up, that are described morecompletely below, and so forces the signal on terminal UPMBCLKR low.Terminal UPMBCLKR is connected to terminal UPMBCLK, external to MBIC700-1, by a resistor, that in one embodiment is a 100 Kohm resistor.

Terminal UPMBDATAR is connected to a drain of field effect transistor(FET) 791. The source of FET 791 is grounded. Bus state control logiccircuit 760 drives gate of FET 791. Control logic circuit 760 drives thegate of FET 791 in state Post-Get, that is described more completelybelow, and so forces the signal on terminal UPMBDATAR low. TerminalUPMBDATAR is connected to terminal UPMBDATA, external to MBIC 700-1, bya resistor, that in one embodiment is a 100 Kohm resistor.

Terminal PMBCLKR is connected to a drain of field effect FET 792. Thesource of FET 792 is grounded. Bus state control logic circuit 760drives gate of FET 792. Control logic circuit 760 drives the gate of FET792 in state Pre-get, that is described more completely below, and soforces the signal on terminal PMBCLKR low. Terminal PMBCLKR is connectedto terminal PMBCLK, external to MBIC 700-1, by a resistor that in oneembodiment is a 100 Kohm resistor. Terminals UPMBCLKR, UPMBDATAR, andPMBCLKR are used for noise suppression.

Terminal/TEST is the same as terminal/TRIBUFF. All other features ofMBIC 700-1 are equivalent to those of MBIC 700.

Operation of a MBIC

MBIC 700 and MBIC 700-1 each include a state machine, in bus statecontrol logic circuit 760, which supports the IDCS bus protocol as shownin the state diagram 850 of FIG. 8. For each state, buffers on the lefthand side are the upstream buffers, i.e., the upstream port, as shown inFIGS. 4, 7A and 7B; the buffers on the right hand side are thedownstream buffers, i.e., the downstream port; and the buffers in themiddle are the peripheral device buffers, i.e., the peripheral deviceport. The buffers indicate the direction of information flow and sodesignate which buffers in FIGS. 7A and 7B are active. Specifically, ashaded buffer in FIG. 8 denotes the port chosen as the source of thecommand clock signal. An unshaded buffer denotes an active signal linethat is not the source of command clock. An unshaded buffer that isgrounded denotes a disabled signal line. The reference numeral PAdenotes the address of a particular MBIC on IDCS bus 150, whilereference numeral A denotes the address in the command. Referencenumeral PER denotes a peripheral device initiated command.

The state machine has a total of ten states, state #0 through state #9,which have reference numerals 800 to 809, respectively. Power-On state800 (State #0) is entered in response (i) to a signal Power-On-Reset,e.g., the signal on terminal/PON is asserted, (ii) to commandSet-Hardware-Reset, and (iii) to MBIC 700 detecting a Parity-Error. Inpower-on state 800, the signal driven on terminal UPINTOUT by interruptlogic 770 depends on the manner in which power-on state 800 was reached.In response to signal power-on-reset or command Set-Hardware-Reset, busstate control logic circuit 760 sends a signal to interrupt logic 770that in turn forces terminal UPINTOUT to a logic zero level.Alternatively, if MBIC 700 detects a Parity-Error, bus state controllogic circuit 760 sends a signal to interrupt logic 770 that in turnforces terminal UPINTOUT to a logic one level. Both peripheral anddownstream interrupts are disabled in state power-on 800 by interruptlogic 770.

The transition from power-on state 800 to No-Address state 801 (State#1) occurs when bus dispatch 305 senses the interrupt signal fromterminal UPINTOUT and issues a start of transmission command SOT toinitiate assign address sequence 604. In no-address state 801, bus statecontrol logic circuit 760 generates a signal to interrupt logic 770 thatin turn forces the signal on terminal UPINTOUT to a logic one level. Busstate control logic circuit 760 also generates signals on lines 714,719, 724, and 736 to multiplexers 713, 718, 723, and 735 so that thegrounded line is connected to the corresponding three-state buffer 712,717, 722, and 732 respectively.

After bus dispatch 305 issues command SOT, bus dispatch 305 issuescommand Assign-Address. In response to command Assign-Address, MBIC 700clears the interrupt and takes on the address in the command. The statemachine transitions from no-address state 801 to last-idle state 803(State #3). In last-idle state 803, interrupts from downstreamperipheral devices are enabled and inverted, but interrupts from theperipheral device on terminal PINTIN are enabled only after bus dispatch305 issues a command Interrupt-Poll to the peripheral device containingMBIC 700 at the newly assigned address. MBIC 700 does not pass thesecond byte of any command to the peripheral device until the peripheraldevice has asserted an interrupt on terminal PINTIN and a command hasbeen issued by bus dispatch 305. This protocol prevents an erroneouspartial pass through of the command byte to the microcontroller. Instate last-idle 803, the downstream buffers remain grounded, i.e.,terminated, thereby ensuring proper termination of IDCS bus 150.

If another peripheral device is connected to IDCS bus 150 downstreamfrom the peripheral device containing MBIC 700, bus dispatch 305, upondetecting the interrupt from the newly connected peripheral device,performs a process in which command Assign Mid-Peripheral is issued toMBIC 700. In response to command Assign Mid-Peripheral, MBIC 700transitions from last-idle state 803 to mid-idle state 802. Bus statecontrol logic circuit 760 changes the signals on lines 714 and 719, tomultiplexers 713 and 718 so that the signals on lines UPCLK an UPDATArespectively are passed therethrough to three-state buffers 712 and 716respectively. The newly connected peripheral device comes up inlast-idle state 803, as described above. In one embodiment, when thenewly connected peripheral device is removed from IDCS bus 150, busdispatch 305 transmits command Assign-Last Peripheral to MBIC 700 andMBIC 700 transitions from mid-idle state 802 to last-idle state 803.

Prior to issuance of commands Send or Get by bus dispatch 305, IDCS bus150 is in a quiescent state which means that each MBIC in IDCS bus 150is either in last-idle state 803 or mid-idle state 802 (State #2).Notice that in state diagram 850, the direction of the information flowfor all states except those associated with command Get is pointingdownstream. There is only one state 809 (State #9) associated withcommand Send. This sole send state 809 contributes to the simplicity ofthe overall IDCS bus command structure, and is possible because withIDCS bus 150, directional turn-around of the buffers in MBIC 700 is notrequired since the buffers of all daisy-chained peripheral devices arealready pointing in the correct (default downstream) direction forsending data downstream upon receiving command Send.

In contrast, the implementation of a command Get-xxx (Get) requires fiverelated states, Pre-Pass-Up state 804, Pass-Up state 805, Pre-Get state806, Get state 807, and Post-Get state 808, i.e., states #4, #5, #6, #7,and #8, respectively. The relative complexity associated with commandGet arises from the need to turn the direction of IDCS bus 150 around(upstream) before a transfer of data from a peripheral device to busdispatch 305 can take place. These command Get related states aredescribed in greater detail below.

Prior to considering the operation of the state machine in response tocommand Send. The sequence of operations in executing command Send aredescribed. Initially, bus dispatch 305 transmits command Send with thestructure in FIG. 5C, as described above, that includes peripheraldevice address A. Next, bus dispatch 305 transmits the data. Finally,bus dispatch 305 transmits an end of transmission command EOT toindicate that all data has been sent.

Command logic circuit 780, as described more completely below, processesthe information from bus dispatch 305 and determines both the command opcode and peripheral device address A transmitted by bus dispatch 305.Command logic circuit 780 sends address A and peripheral address PA tobus state control logic circuit 760 along with the command op code. Busstate control logic circuit 760 compares address A and peripheraladdress PA to determine the relationship between the two addresses. Uponbus state control logic circuit 760 detecting command Send with addressA equal to address PA, the state machine transitions from the idlestate, either last-idle state 803 or mid-idle state 802 to send state809. In send state 809, bus state control logic circuit 760 generatessignals that in turn pass the signals on terminals UPMBCLK and UPMBDATAto terminals PMBCLK and PMBDATA respectively, i.e., appropriate controlsignals are generated to multiplexers 723 and 735 and to three-statebuffers 722 and 732. The downstream data and clock lines are connectedto ground, as described above for last-idle state 803.

The state machine remains in state send 809 until command logic circuit780 detects end-of-transmission command EOT. Upon detection of commandEOT, bus state control logic circuit 760 transitions back to theappropriate idle state, as determined by the position of MBIC 700 onIDCS bus 150.

The basic execution of command Get is similar to that for command Sendwhen the reversal of data travel is considered. Initially, bus dispatch305 transmits command Get with the structure described above thatincludes the peripheral device address A. The actions taken by MBIC 700in response to command Get depends on whether address PA of MBIC 700matches address A in the command.

If the addresses do not match and address A is less than address PA,MBIC 700 must configure itself to transmit data to bus dispatch 700. Ifaddress A is greater than address PA, MBIC 700 remains in the idlestate. If address A equals address PA, the peripheral device containingMBIC 700 acknowledges command Get with command SOT. The peripheraldevice then transmits the data followed by a command EOT. Finally, busdispatch 305 acknowledges with a command EOT.

Upon issuance of command Get by bus dispatch 305, if address A in thecommand is not for the peripheral device closest to bus dispatch, 305,i.e., the first peripheral device on IDCS bus 150, all MBICs upstreamfrom the MBIC with address A, with the exception of the MBIC in theperipheral device closest to dispatch 305, i.e., the MBIC with addresssix, transition from middle state 802 to pass-up state 805.Specifically, assuming MBIC 700 is in such a position, in response tosignals from command logic circuit 780, bus state control logic circuit760 determines that a command Get has been received and that address PAof MBIC 700 is greater than address A in command Get. In state pass-up805, three-state buffers 712 and 717 are tri-stated while buffers 702and 707 are enabled and multiplexers 703 and 708 are provided controlsignals that pass the downstream signals therethrough. Control signalsare applied to multiplexers 723 and 735 to select the grounded line.

The MBIC in the peripheral device closest to dispatch 305, i.e., theMBIC with address six, transitions from mid-idle state 802 topre-pass-up state 804. Specifically, assuming MBIC 700 is in such aposition, in response to signals from command logic circuit 780, busstate control logic circuit 760 determines that a command Get has beenreceived and that address PA of MBIC 700 is greater than address A incommand Get. In state pre-pass-up 804, three-state buffers 702, 707,712, and 717 are tri-stated so that any contention with bus dispatch 305is blocked. Control signals are applied to multiplexers 723 and 735 toselect the grounded line and three-state buffers 722 and 732 areenabled.

In response to command Get, the MBIC with address PA equal to address Atransitions from the appropriate idle state, i.e., either state mid-idle802 or state last-idle 803 depending on the position of the MBIC, tostate get 807. In state get 807 for MBIC 700, bus state control logiccircuit 760 sends signals on lines 714 and 719 to multiplexers 713 and718 respectively to select the grounded lines and enables three-statebuffers 712 and 717. Bus state control logic circuit 760 also sendscontrol signals to enable buffers 702 and 707, to select peripheraldevice signal PCLK from multiplexer 703 and peripheral device signalPDATA from multiplexer 708, and to open buffers 722 and 732. Themicrocontroller coupled to MBIC 700 generates a start of transmissionsignal SOT to indicate that data transmission is starting.

In response to the start of transmission command SOT by the peripheraldevice, the MBIC with an address of 6, i.e., the MBIC in the peripheraldevice closest to base station 100, transitions from pre-pass up state804 to pass up state 805, that was described above. Thus, a completedata path is established from the addressed peripheral device to busdispatch 305.

When the data transmission is complete, the addressed peripheral devicegenerates an end of transmission command EOT to bus dispatch 305. Inresponse to the end of transmission command EOT from the peripheraldevice, each of the upstream peripheral devices transitions from pass-upstate 805 to mid-idle state 802, i.e., the data and clock line buffersand multiplexers directions are reversed so that the data and clockdirections are pointing downstream from bus dispatch 305.

The MBIC in the addressed peripheral device transitions from get state807 to post-get state 808 upon generation of the end of transmissioncommand EOT by the peripheral device. In state post-get 808, thedirection of upstream buffers 702 and 707 are open. Buffers 722 and 741driving the peripheral data and clock terminals PMBDATA and PMBCLK aretri-stated so as to avoid a bus contention while the MBIC is still in abus master mode. Downstream buffers 712 and 717 remain enabled andconnected to ground. In response to end of transmission command EOT fromthe peripheral device, bus dispatch 305 acknowledges the end oftransmission by echoing back an end of transmission command EOT. Inresponse to end of transmission EOT, the MBIC in the addressedperipheral device for command Get transitions to the appropriate idlestate, i.e., either last-idle state 803 or mid-idle state 802.

The above process for command Get is followed for all MBIC's except whenthe command is addressed to the MBIC in the peripheral device attacheddirectly to bus dispatch 305. In this situation, in response to commandGet, the MBIC with address 6 transitions from the appropriate idle,i.e., mid-idle state 802 or last-idle state 803 to pre-get state 806. Inpre-get state 806, the upstream buffers i.e., buffers 702 and 707, aretri-stated so as to avoid a bus contention. The downstream buffers 712and 717 are sent a signal to enable the buffers and a select signal issupplied to multiplexers 713 and 718 so that the grounded line isselected. Buffers 732 and 722 are tri-stated so that the clock and datalines connected to the peripheral device are set to receive the clockand data signals. When the peripheral device issues a start oftransmission command SOT, command SOT is detected by command logiccircuit 780 in MBIC 700 and in response thereto, bus state control logiccircuit 760 transitions from pre-get state 806 to get state 807 that waspreviously described.

Interrupt Logic Circuit

Interrupt logic 770 (FIGS. 7A and 7B) was described above in generalterms with respect to the operation of the MBICs in FIG. 4 and also withmore specificity in the description of state diagram 850 (FIG. 8). Asexplained previously, interrupt logic 770 generates hardware interruptsto bus dispatch 305 in three situations. The first is when a peripheraldevice is first attached to IDCS 150. The second is when MBIC 700 makesa transition from a Power-On state to a No-Address state as describedabove. The third is when MBIC 700 detects a Parity-Error. In addition,interrupt logic 770 passes upstream interrupts from downstreamperipheral devices.

Interrupts from a downstream peripheral device, drivedownstream-interrupt-in terminal DNINTIN which is processed by interruptlogic circuit 770. Interrupt logic circuit 770 also receives aninterrupt signal from peripheral-interrupt-in terminal PINTIN that isdriven by a bi-directional peripheral interrupt line. In thisembodiment, during normal operation, an interrupt signal at bus dispatch305 of base station 100 is active high.

Interrupt logic circuit 770 provides the following functions:

1) In state power-on, the signal on upstream-interrupt-out (UPINTOUT)terminal of MBIC 700 is negated, i.e., the signal on terminal UPINTOUTis set to a logic zero level, and peripheral device and downstreaminterrupts are masked;

2) In state No-Address, i.e., before bus dispatch 305 has assigned anaddress to MBIC 700, the signal on terminal UPINTOUT is set to a logicone level and downstream interrupts are enabled, but peripheral deviceinterrupts remain masked;

3) If MBIC 700 has not been assigned Last-Peripheral status, the signalon terminal UPINTOUT is the logical OR function of any signal onterminal PINTIN and any signal on the downstream-interrupt-line terminalDNINTIN, i.e., signal UPINTOUT=(signal PINTIN) OR (signal DNINTIN); and

4) If MBIC 700 has been assigned Last-Peripheral status, any signal fromterminal DNINTIN is inverted before being ORed with the signal onterminal PINTIN, i.e. signal UPINTOUT=(signal PINTIN) OR(signal/DNINTIN).

A fifth and final requirement for the interrupt protocol for thisinvention is when MBIC 700 is in state last-idle 803, the signal onterminal DNINTIN is pulled high. As explained more completely below, inone embodiment, this final requirement is accomplished with circuitryexternal to MBIC 700.

The initial default state generated by interrupt logic circuit 770 whenMBIC is in state power-on, i.e., the first function above, assures thatthe signal on terminal DNINTIN of the peripheral device immediatelyupstream of the peripheral device containing MBIC 700 goes low when theperipheral device containing MBIC 700 is docked to that upstreamperipheral device. The fourth function described above assures that theupstream peripheral device, which is the last peripheral device, invertsthe signal received on terminal DNINTIN. Consequently, the first andfourth functions combined guarantee that the interrupt signal isgenerated on terminal UPINTOUT of the last peripheral device when a newperipheral device is docked onto IDCS bus 150.

Similarly, the third and fifth functions guarantee that when aperipheral device is disconnected from IDCS bus 150, terminal DNINTIN ofthe MBIC in the last peripheral device on IDCS bus 150 after thedisconnect is pulled to IDCS bus voltage supply MBVCC. The result is thegeneration of an upstream interrupt toward dispatch 305 when aperipheral device is removed, since mid-peripheral devices do not invertany downstream interrupts. Hence, the resulting interrupt informsdispatch 305 of an impending new IDCS bus configuration.

Hence, when a peripheral device is first added to IDCS bus 150, thesignal on terminal UPINTOUT of newly connected peripheral device isforced to a logic zero. This logic zero value drives terminal DNINTIN ofthe next upstream peripheral device. As explained above, the nextupstream peripheral device inverts the signal on terminal DNINTIN sothat an interrupt eventually arrives at bus dispatch 305. Bus dispatch305 then issues a start of transmission SOT signal followed by commandInterrupt-Poll, that was discussed above.

Command Interrupt-Poll enables bus dispatch 305 to determine whichperipheral device is the source of the IDCS bus interrupt. When aninterrupting peripheral device is interrupt polled, interrupt logic 770enables internal peripheral interrupt terminal PINTIN (FIGS. 7A and 7B)and disables downstream interrupt terminal DNINTIN (FIGS. 7A and 7B).Upstream from the polled interrupting peripheral device, MBICs disableperipheral interrupt terminal PINTIN and enable downstream interruptterminal DNINTIN. MBICs downstream from the polled interruptingperipheral device enable both peripheral interrupt terminal PINTIN anddownstream interrupt terminal DNINTIN.

The response to a command Error Poll by the MBICs on IDCS bus 150 isidentical to that just described for command Interrupt-Poll exceptinterrupt circuit 770 in the MBIC being polled disables both downstreamand peripheral device interrupts.

Circuit 900 (FIG. 9) within interrupt circuit 770 is used, in thisembodiment, (i) to invert signals from terminal DNINTIN in the lastperipheral device; (ii) to mask the peripheral device and downstreaminterrupts; (iii) to generate the low signal on terminal UPINTOUT; (iv)and to generate the parity error interrupt. MBIC interrupt line MBICINTis connected to a first input terminal of OR gate 901. When the signalon line PON to interrupt logic circuit 770 goes active, interrupt logiccircuit 770 drives the signal on line MBICINT low. Interrupt logiccircuit 770 in response to signals from bus state control logic circuit760 also drives low signals on enable downstream interrupt line ENADNINTand enable peripheral device interrupt line ENPERINT to AND gate 902 andgate 903, respectively. Consequently, the output signal of AND gate 902to a second input terminal of OR gate 901 and the output signal of ANDgate 903 to a third input terminal of OR gate 901 are both low.Therefore, the output signal of OR gate 901 on line UPINT to buffer 742is also low and so the signal on terminal UPINTOUT is low.

Exclusive OR gate 904 has a first input terminal connected to line LASTand a second input terminal connected to line DNINT that is driven bythe signal on terminal DNINTIN. The signal on line LAST is low exceptwhen the peripheral device containing the MBIC is assigned lastperipheral status, in which case the signal on line LAST is high. Thus,when signal LAST is low, the signal on line DNINT is passed throughexclusive OR gate 904 to a second input terminal of AND gate 902.Conversely, when signal LAST is high, exclusive OR gate 904 inverts thesignal on line DNINT. The signal on line ENADNINT to AND gate 902 isused to mask the signal from exclusive OR gate 904 when downstreaminterrupts are disabled.

Peripheral interrupt line PERINT from terminal PINTIN is connected to asecond input terminal of AND gate 903. The signal on line ENPERINT toAND gate 903 is used to mask the signal on line PERINT when interruptsfrom the peripheral device are disabled. The signal on line MBICINT isdriven high when the MBIC detects a parity error.

Command Logic Circuit

FIG. 10 is a more detailed logic block diagram of one embodiment of thecommand logic circuit 780 and control logic circuit 760 (FIGS. 7A and7B). In FIG. 10, multiplexers 755 and 756 (FIGS. 7A and 7B) are combinedand shown as multiplexer 1031. Clock signal CMDCLK from multiplexer 1031to the clock terminal of shift register 1032 is one of input signalsUPDATA, DNDATA, and PDATA to multiplexer 1031. Clock signal CMDCLK alsodrives a four-bit message bit counter 1033 that counts the sixteen clockpulses associated with a command. The output signal from message bitcounter 1033 is provided to decode and comparator circuit 1034. Decodeand comparator circuit 1034 and register 1037 implement state diagram850.

Shift register 1032 loads bits REV2, MBI and A0 to A2 in the commandinto a REV2/MBI/ADD latch 1035. Signals from decode and comparatorcircuit 1034 enable the clock to latch 1035. The circuitry in MBIC 700is synchronous and so clock enable signals are used to clock a componentat the appropriate time. When message bit counter 1033 detects the endof the second byte of the command, shift register 1032 is frozen holdingthe command code and a parity bit PAR.

The five command bits are passed from shift register 1032 to decode andcomparator circuit 1034. When decode and comparator circuit 1034 detectsan assign-address command, a clock enable signal is provided toperipheral device address latch 1036 so that address signal ADD fromlatch 1035 in turn is clocked into peripheral device address latch 1036.Address signal ADD and peripheral address signal PADD are both providedto decode and comparator circuit 1034 so that circuit 1034 can determinewhen the address in a command is directed to the MBIC as well as whenthe address in the command is less than or greater than the address ofthe MBIC. Similarly, signals REV2 and MBI from latch 1035 are providedto decode and comparator circuit 1034 so that circuit 1034 can determinewhen to pass the second byte of a command to the microcontroller. Decodeand comparator circuit 1034 generates the state of the MBIC, e.g.,mid-peripheral idle or last-peripheral idle. The present state of theMBIC is loaded in state register 1037. The next state of the MBIC is onthe input line to state register 1037.

FIG. 11A illustrates one embodiment of a command detector 1101 withindecode and comparator circuit 1034. FIG. 11B illustrates one embodimentof message bit counter 1033. Command detector 1101 detects the swappingof the clock and data signals used to transmit commands, as discussedabove. FIG. 12 is a timing diagram for command transmission thatincludes the waveforms for the internal nodes of command detector 1101and message bit counter 1033.

Signal CMDCLK from multiplexer 756 is driven by the signal on lineUPDATA during transmission of a command while signal CMDDATA frommultiplexer 755 is driven by the signal on line UPCLK. Detector 1101operates on the principle that during normal data flow there will not beany data transitions without an equivalent clock transition, i.e., theclock transition generates the data.

In particular, in detector 1101, signal CMDCLK drives the clockterminals of negative-edge triggered, i.e., falling-edge triggered,flip-flops 1102 and 1103. The input terminal of flip-flop 1102 isconnected to IDCS bus power supply voltage MBVCC and the output terminalis connected to the input terminal of flip-flop 1103. The outputterminal of flip-flop 1103 drives the clock terminal of positive-edgetriggered flip-flop 1104 that has its input terminal connected to IDCSbus power supply voltage MBVCC. The invertors on the clear terminals offlip-flops 1102 and 1103 are driven by the output signal of AND gate1106. AND gate 1106 is driven by the complement of power-on signal PON,signal CMDDATA, and the complement of down count enable signal DCNTEN.During data transmission, the complement of power-on signal PON and thecomplement of down count enable signal DCNTEN are normally high.Consequently, the output signal of AND gate 1106 is determined by thelevel of signal CMDDATA.

Thus, in a normal data transmission, the clock signal on line CMDDATAclears flip-flops 1102 and 1103 so that any data signal on line CMDCLKcan not clock the logic one value through flip-flop 1103. However, whenthe command is transmitted, as shown in FIG. 12, the signal on lineCMDDATA is held high for two clock periods. Consequently, the firstfalling edge on line CMDCLK clocks a logic one through flip-flop 1102 toflip-flop 1103. The next falling edge on line CMDCLK clocks a logic oneon line D2 as shown in FIG. 12. Thus, flip-flops 1102 and 1103 areconfigured to detect two consecutive falling edges on line CMDCLKwithout any low going pulses on line CMDDATA. Hence, to ensure propercommand detection, the first two bits of every command are always set toa logic one. The rising edge on line D2 clocks flip-flop 1104 so that alogic one is driven onto the output terminal of flip-flop 1104. Thesignal on the output terminal of flip-flop 1104 drives the inputterminal of flip-flop 1105, counter enable line CNTEN, an input terminalof AND gate 1108 and invertor 1107 that in turn drives counter enablecomplement line/CNTEN. The second input terminal of AND gate 1108 isdriven by the output signal of invertor 1109. The input terminal ofinvertor 1109 is driven by the output terminal of flip-flop 1105. Theinvertor on the clear terminal of flip-flop 1105 is driven by thecomplement of the signal on power-on line PON. The complement of thesignal on power-on line PON also drives a first input terminal of ANDate 1110 and a second input terminal of AND gate 1110 is driven by thecomplement of load state signal on line LDSTATE. A signal on the outputterminal of AND ate 1110 drives an inventer on the clear terminal offlip-flop 1104.

Hence, each time the signal goes active on load state line LDSTATE, theresulting low signal from AND gate 1110 clears flip-flop 1104. The clockterminal of flip-flop 1105 is driven by the signal on line CMDCLK. Thus,a logic zero value is clocked through flip-flop 1105 by each fallingedge on line CMDCLK after flip-flop 1104 is cleared. Consequently, whenthe logic one signal on line D2 is applied to line CNTEN and the firstinput terminal of AND gate 1108, the signal on the second input terminalof AND gate 1108 is also high so that AND gate 1108 drives the signalhigh on load count line LDCNT, as shown in FIG. 12. The active signalson lines CNTEN and LDCNT drive enable terminal EN and load terminal LD,respectively of four bit down counter 1150 (FIG. 11B).

The active signal on line CNTEN also drives an input terminal of ANDgate 1155. A second input terminal of AND gate 1155 is driven by theoutput signal of NAND gate 1153 and a third input terminal of AND gate1155 is driven by the output signal of NAND gate 1154. As shown in FIG.12, when the signal on count enable line CNTEN is inactive, the outputsignal of counter 1150 on terminals Q 3:0! is zero and so the outputsignals of NAND gates 1153 and 1154 are both high. Consequently, theactive signal on line CNTEN drives the output signal of AND gate 1155 onshift line SHFT active. The active signal on shift line SHFT enablesshift register 1032 (FIG. 10).

The third falling edge on line CMDCLK clocks a logic one value intoflip-flop 1105 and so invertor 1109 drives the output signal on loadcount line LDCNT low. The resulting pulse on load count line LDCNT, inthis embodiment, loads a value of 0Ch in four-bit down counter 1150because least significant bit terminals DO and D1 are grounded and mostsignificant bits D2 and D3 are tied to IDCS bus power supply voltageMBVCC. The value of counter 1150 is shown on line CNT in FIG. 12.

After counter 1150 is loaded, each subsequent falling edge on lineCMDCLK decrements counter 1150. A load peripheral device address signalLDADD is issued to latch 1035 when counter 1150 reaches a value of nine.Signal LDADD enables the clock to latch 1035 so that latch 1035 isloaded with the contents of five-bit command shift register 1032.

When counter 1150 reaches a value of eight the signal on line PEREN isdriven active, and the decode and comparator circuit 1034 compares theaddress stored in latch 1035 with the address stored in latch 1036 todetermine whether the command is directed to the peripheral devicecontaining this MBIC. When counter 1150 reaches a value of seven, thesignal on peripheral enable line PEREN is driven inactive, and themicrocontroller is informed whether the command is intended for thisperipheral device. If the address matches and bit MBI is not set, thesecond byte of the command is passed through to the microcontroller.

When counter 1150 reaches a value of two, the signal on line SHFT toshift register 1032 is driven low so that the op code for the command iscaptured in shift register 1032. When counter 1150 has a value of zero,the signal on load state line LDSTATE is driven active. Consequently,the output signal from AND gate 1110 goes low and flip-flop 1104 iscleared and the signal on counter enable line CNTEN goes low.

Synchronization Circuit

FIG. 13 is a more detailed schematic diagram of the synchronizationcircuits inserted in the output line of multiplexer 723 (FIG. 7A) toobtain multiplexer and synchronization circuit 723-1 (FIG. 7B) and inthe output line of multiplexer 735 (FIG. 7A) to obtain multiplexer andsynchronization circuit 735-1 (FIG. 7B). Line PERCLK is the output linefrom multiplexer 735 and line PERDATA is the output line frommultiplexer 723. Flip-flops 1301 and 1302 and multiplexer 1303 are inmultiplexer and synchronization circuit 735-1. Flip-flops 1311 and 1312and multiplexer 1313 are in multiplexer and synchronization circuit723-1. Flip-flop 1315 is shared by multiplexer and synchronizationcircuits 723-1 and 735-1.

The signal on line PERCLK drives the input terminal of flip-flop 1301and a first input terminal of multiplexer 1303. The signal on the inputterminal of flip-flop 1301 is clocked through flip-flop 1301 to an inputterminal of flip-flop 1302 by a rising edge on line OSCEDGE that isdriven by the output signal of exclusive OR gate 757, (FIG. 7B) that wasdescribed above. The signal on the input terminal of flip-flop 1302 isclocked through flip-flop 1302 to a second input terminal of multiplexer1303 by a second rising edge on line OSCEDGE.

Similarly, the signal on line PERDATA drives the input terminal offlip-flop 1311 and a first input terminal of multiplexer 1313. Thesignal on the input terminal of flip-flop 1311 is clocked throughflip-flop 1311 to an input terminal of flip-flop 1312 by a rising edgeon line OSCEDGE that is driven by the output signal of exclusive OR gate757, that was described above. The signal on the input terminal offlip-flop 1312 is clocked through flip-flop 1312 to a second inputterminal of multiplexer 1313 by a second rising edge on line OSCEDGE.

The signal passed through multiplexer 1303 to line PMBCLK and the signalpassed through multiplexer 1313 to line PMBDATA is determined by signallevel on line SELS from flip-flop 1315. Initially, when the signal onpower-on line PON is driven active, flip-flops 1301, 1302, 1311, 1312and 1315 are cleared. Hence, the signal level on line SEL is low so thatmultiplexers 1303 and 1313 pass the unsynchronized signals on linesPERCLK and PERDATA, respectively therethrough.

The input terminal of flip-flop 1315 is connected to IDCS bus powersupply voltage MBVCC and the clock terminal receives the signal on lineOSCEDGE. Consequently, the first rising edge on line OSCEDGE clocks alogic one through flip-flop 1315 and thereafter, the synchronized signalis passed through multiplexers 1303 and 1313. Grounding terminal OSC ofMBIC 700-1 (FIG. 7B) forces the synchronization logic of FIG. 13 toalways select the unsynchronized signals.

The two flip-flop shift registers 1301, 1302 and 1311, 1312 perform thesignal synchronization. First flip-flop 1301, 1311 performs the actualsynchronization function, while second flip-flop 1302, 1312 removes anymetastability introduced by first flip-flop 1301, 1311. The signal online OSCEDGE must have a frequency which is at least four times thefrequency expected for signal on either line PMBCLK or line PMBDATA. Thefrequency of the signal on line OSCEDGE must be low enough to guaranteethat second flip-flop 1302, 1312 is able to resolve any metastabilitiesgenerated by first flip-flop 1301, 1311.

As explained above, the signal on line OSCEDGE that is driven by theoutput signal of exclusive 0R gate 757 in response to signals onterminals OSCEDGSEL and OSC. Thus, grounding terminal OSCEDGSEL causessynchronization to occur at the positive edge of a signal on terminalOSC. Conversely if terminal OSCEDGSEL is hardwired to a logic one,synchronization occurs at the negative edge of a signal on terminal OSC.

As explained above, the IDCS bus power protocol of this inventionincludes three different features, i.e., (1) MBIC 700 is powered by busdispatch 305, (2) a new peripheral device is plugged into MBIC 700 whilepower is supplied to MBIC 700 by base station 100, and (3) bus dispatch305 may power-up or power-down the peripheral device containing MBIC700. Preferably, the first two IDCS bus power protocol features arealways supported while support of the third feature is optional. Each ofthese power protocols are considered in more detail below in theconsiderations of implementation of MBIC 700 and MBIC 700-1 in aperipheral device. When only a single reference number for an MBIC isused, in view of the similarities of MBIC 700 and MBIC 700-1, thoseskilled in the art will appreciate that the description is applicable toboth embodiments.

Implementation of a MBIC in a Peripheral Device

FIG. 14 illustrates one configuration of MBIC 700-1 (FIG. 7B) in aperipheral device that supports each of the IDCS bus power protocols. Asshown in FIG. 14, line 1406 connects pins 1407 and 1408 in theconnectors used to interconnect peripheral devices on IDCS bus 150. MBIC700-1 is powered by IDCS bus power supply voltage MBVCC from line 1406,while microcontroller 416 is powered from by peripheral device powersupply voltage CPUVCC. Peripheral device power supply voltage CPUVCC ispreferably supplied from a separate power source, such as a battery oran external transformer. Depending on their function, some types ofperipheral devices maintain power supply voltage CPUVCC asserted, whileother peripheral devices switch power supply voltage CPUVCC off whenIDCS bus power supply voltage MBVCC is powered-down.

A resistor 1401 is connected between line 1406 carrying IDCS bus powersupply voltage MBVCC and input terminal VCC of MBIC 700-1. Thus, wheneither the peripheral device containing MBIC 700-1 is hot-plugged toIDCS bus 150, or IDCS bus power supply voltage MBVCC is turned on by busdispatch 305, resistor 1401, which, in one embodiment, has a resistanceof fifteen ohms, prevents current surges into MBIC 700-1 and theperipheral device. Further, resistor 1401 limits the current that can bedrawn by MBIC 700-1 and the peripheral device so that the power supplyin base station 100 can respond to the current requirements withoutcausing an excessive voltage sag on line MBVCC, e.g., the voltage online MBVCC stays with ±10% of its nominal value.

Thus, resistor 1401, in this embodiment, permits hot-plugging of aperipheral device containing MBIC 700-1. However, use of a resistor isillustrative only and is not intended to limit the invention to thisparticular embodiment. In view of this disclosure, those skilled in theart can utilize a variety of techniques to limit the currentrequirements on power-up of a MBIC.

A variety of features are used to support power-down of IDCS bus supplyvoltage MBVCC by bus dispatch 305. In this embodiment, all signals frommicrocontroller 1410 to MBIC 700-1 are routed through buffers that arepowered by IDCS bus power supply voltage MBVCC, and that do not havediodes connected to the power supply voltage. For example, signals OSC,SWAP and PINTIN from microcontroller 1410 to MBIC 700-1 are buffered byAND gates 1402, 1403, and 1404, which do not have diodes coupled to theIDCS bus power supply voltage MBVCC. In one embodiment, AND gates 1402to 1404 are in an integrated circuit that is commonly sold as partnumber 74VHC08. The important aspect is to isolate the CMOS circuitry ofMBIC 700-1 using appropriate buffers so that if a peripheral deviceasserts a signal to MBIC 700-1 while IDCS bus power supply voltage MBVCCis powered-down, latch-up does not occur when IDCS bus power supplyvoltage MBVCC is powered-up.

Power-Down Protocol

In a normal power-down of IDCS bus power supply voltage MBVCC, busdispatch 305 informs all peripheral devices on IDCS bus 150 of theintention to power-down IDCS bus power supply voltage MBVCC via commandPower-Warning. See Table IV above. If microcontroller 1410 detects thatIDCS bus power supply voltage MBVCC is off, microcontroller 1410configures its I/O pins to conserve power.

If IDCS bus power supply voltage MBVCC shut-down occurred only in anorderly fashion in response to a command from bus dispatch 305,buffering between microcontroller 1410 and MBIC 700-1 would not berequired. However, power to MBIC 700-1 can also be lost by removal ofthe peripheral device from IDCS bus 150 while IDCS bus power supplyvoltage MBVCC is on. When the peripheral device is removed from IDCS bus150 in such a manner, there is no time for an orderly shut-down of MBIC700-1, and therefore buffering is essential.

As explained above, buffers 1402 to 1404 do not have diodes coupled toIDCS bus power supply voltage MBVCC and hence do not cause latch-up ifan input signal is left at a logic one when IDCS bus power supplyvoltage MBVCC is re-powered. Bi-directional buffer 1405, which, in thisembodiment, is an integrated circuit sold as part number 74VLT255, alsodoes not have any diodes coupled to IDCS bus power supply voltage MBVCC.

The final power protocol that must be considered is the powering-down ofthe peripheral device containing microcontroller 1410 and MBIC 700-1 byturning off power supply voltage CPUVCC while MBIC 700-1 is powered. Toconfigure MBIC 700-1 properly, the signal on line PPWRDWN to MBIC 700-1must be driven active before powering down microcontroller 1410. Whensignal PPWRDWN is asserted, MBIC 700-1 either tri-states or drives tologic zero lines between MBIC 700-1 and microcontroller 1410. An exampleof a power down is when a user inadvertently disconnects the powersource of the peripheral device. Specifically, in one embodiment, toprevent latch-up, MBIC 700-1, upon detecting the assertion of the signalPPWRDWN, forces all output terminals connected to microcontroller 1410to a logic zero. Moreover, to minimize power losses due to floatinginputs, MBIC 700-1 forces all input terminals from microcontroller 1410to a logic zero.

Peripheral Device Power Up

MBIC 700-1 also offers a means of powering up peripheral device powersupply voltage CPUVCC by furnishing a signal on output line PPWRON. Busdispatch 305 issues commands Set Peripheral Power-on and ClearPeripheral Power-on, respectively, to MBIC 700-1 to assert and deasserta signal on line PPWRON. If signal PPWRON is asserted, power typicallyis supplied to microcontroller 1410 only when IDCS bus power supplyvoltage MBVCC is powered on. If microcontroller 1410 needs to be poweredwhen IDCS bus power supply voltage MBVCC is not powered on, additionalcircuitry is provided to allow peripheral device power supply voltageCPUVCC to be turned on while IDCS bus power supply voltage MBVCC is off.In such a case, peripheral power supply voltage CPUVCC may still bepowered off by using signal PPWRON.

In the embodiment illustrated in FIG. 14, signal PPWRON provides acontrol signal for generating peripheral power supply voltage CPUVQCfrom standby voltage source VSTANDBY. Standby voltage source VSTANDBY isa continuous power source such as batteries. When bus dispatch sendscommand Set Peripheral Power-on to MBIC 700-1, MBIC 700-1 drives thesignal on line PPWRON active. The signal on line PPWRON is a first inputsignal to NAND gate 1435, i.e., to the gate of N-channel MOSFET 1436that has a drain connected to IDCS bus power supply voltage MBVCCthrough resistor 1438 and to power down terminal PPWRDWN of MBIC 700-1,and a source connected to a drain of N-channel MOSFET 1437. The signalon line PPWRON is also an input signal to peripheral power supplycontrol circuit 1430, i.e., the signal drives the gate of N channelMOSFET 1431.

The drain of MOSFET 1431 is connected through resistor 1433 to voltagesource VSTANDBY and to the input of invertor 1432, i.e., to the gates ofP-channel power MOSFET 1432A and of N-channel MOSFET 1432B. The sourceof MOSFET 1431 is grounded. Hence, when signal PPWRON is active, MOSFET1431 conducts and so a logic zero value is input to invertor 1432.Consequently, the output of invertor 1432 on line CPUVCC is a logic one.Thus, N-channel MOSFET 1431 is one embodiment of a switch for turningthe peripheral device on and off. The drain is a first terminal of theswitch and the source is a second terminal that is connected to areference voltage. The gate is the switch selector.

The signal on line CPUVCC drives the gate of MOSFET 1437 so that whensignals on lines CPUVCC and PPWRON are both high, the signal on terminalPPWRDWN of MBIC 700-1 is low. Conversely, when the signal on line PPWRONis low, the signal on terminal PPWRDWN is high and the signal on lineCPUVCC is clamped to ground by circuit 1430.

Bus Wake-Up Protocol

IDCS bus 150 is asleep whenever IDCS bus power supply voltage MBVCC ispowered down by bus dispatch 305. To conserve power, bus dispatch 305turns off IDCS bus power supply voltage MBVCC to all the MBICs connectedto IDCS bus 150. However, before dispatch 305 shut downs IDCS bus powersupply voltage MBVCC, bus dispatch 305 broadcasts command Power-Down asdescribed above. When IDCS bus power supply voltage MBVCC is on, IDCSbus 150 supplies +3.3 volts on line MBVCC. Conversely, when IDCS buspower supply voltage MBVCC is off, the voltage level on line MBVCC isclamped to ground, i.e., no current should flow onto line MBVCC from anyperipheral device.

Docking of a peripheral device to a sleeping IDCS bus 150 may gounnoticed, unless the peripheral device is able to generate a Wake-Upinterrupt. Further, each peripheral device upstream of the newly dockedperipheral device must be capable of passing upstream the wake-upinterrupt from the newly docked peripheral device. Alternatively, aperipheral device on IDCS bus 150 can generate a wake-up interrupt torequest that bus dispatch 305 re-energize IDCS bus power supply lineMBVCC.

The generation of the wake-up interrupt in the absence of IDCS bus powersupply voltage MBVCC necessitates a separate power source in the newlydocked peripheral device or in the peripheral device asserting thewake-up interrupt. FIG. 15 shows one embodiment of circuitry forgenerating and propagating wake-up interrupts. The wake-up interrupt isgenerated by forcing signal on terminal UPINT to a logic one, e.g., +3volts in this embodiment. All upstream peripheral devices propagateupstream the wake-up interrupt. Bus dispatch 305 upon sensing theinterrupt powers up IDCS bus power supply voltage MBVCC using theprocess described more completely below. When the peripheral device,which issued the wake-up interrupt senses the IDCS bus power supplyvoltage MBVCC is asserted, the wake-up interrupt signal is immediatelyreleased.

A first embodiment of MBIC 700 interrupt support circuit 1510 can drivean interrupt signal on output terminal UPINT active based on aninterrupt signal from one of three sources, an interrupt signal on inputterminal DNINT, an interrupt signal on output terminal UPINTOUT of MBIC700, or an interrupt signal from wake-up terminal/WAKEUP ofmicrocontroller 1410.

The signal on output terminal UPINTOUT of MBIC 700 drives an inputterminal of invertor 1414 which is powered by IDCS bus power supplyvoltage MBVCC. In one embodiment, invertor 1414 is an invertor that doesnot have a diode connected to the power supply terminal, such as PartNo. 74VHC04 sold by Toshiba. The output signal of invertor 1414 drivesthe input terminal of a discrete invertor 1415.

In one embodiment, discrete invertor 1415 is formed from a P-channelMOSFET 1415A, such as that sold by Siliconix under Part No. TP0202, andan N-channel MOSFET 1415B, such as that sold by Siliconix under Part No.TN0201. The power terminal of MOSFET 1415A is connected to IDCS buspower supply voltage MBVCC through a Schottky diode 1416 such as thatsold by Philips under Part No. BAS85.

Invertor 1415 protects MBIC 700 from latch-up when a wake-up interruptsignal is asserted on output terminal UPINT. Schottky diode 1416, thatis connected in series with the power terminal of invertor 1415,prevents output terminal UPINT from being clamped to ground through theinherent diode in MOSFET 1415A to line MBVCC from the output terminal ofinvertor 1415.

A wake-up interrupt generation circuit 1520 generates a wake-upinterrupt on terminal UPINT when microcontroller 1410 wants IDCS buspower supply voltage MBVCC asserted. As explained more completely below,circuit 1520 includes a driver for driving the wake-up interrupt ontoIDCS bus 150 and a gate to prevent spurious generation of wake-upinterrupts by a malfunctioning microcontroller.

In this embodiment, circuit 1520 has a power supply terminal 1521 thatis connected to peripheral device power supply voltage CPUVCC. Powersupply terminal 1521 supplies a voltage to the emitter of a PNPtransistor 1523. The base of PNP transistor 1523 is connected toterminal/WAKEUP of microcontroller 1410 through a resistor 1524, whichin one embodiment is a 10 Kohm resistor. Terminal/WAKEUP is an I/O portof microcontroller 1410. The signal level on terminal 1521 is alsoconnected to terminal/WAKEUP through resistor 1522, which in thisembodiment is a 100 Kohm resistor. The voltage level provided throughresistor 1522 to terminal/WAKEUP prevents the input signal to circuit1520 from floating when microcontroller 1410 first powers up because allI/O ports are by default input ports when first powered up. Thecollector of transistor 1523 is connected to the emitter of a PNPtransistor 1525. The base of transistor 1525 is connected to IDCS buspower supply voltage MBVCC through resistor 1526, which in thisembodiment is a 10 Kohm resistor. A collector of transistor 1525 isconnected through Schottky diode 1527 to output terminal UPINT. In thisembodiment, transistors 1523 and 1525 and resistors 1524 and 1526 arecontained in a dual PNP 10 Kohm base resistor package sold by Panasonicas Part No. XN4115.

When microcontroller 1410 determines that IDCS bus power supply voltageMBVCC is off by sensing the signal level on the I/O port to whichvoltage MBVCC is supplied and microcontroller 1410 needs to communicatewith bus dispatch 305, microcontroller drives the signal onterminal/WAKEUP low. In response to this signal, transistor 1523provides the required current to generate a wake-up interrupt.Transistor 1525, which is gated by the voltage level on line MBVCC in amanner identical to that described below for transistor 1511, preventsmicrocontroller 1410 from generating a wake-up interrupt when IDCS buspower supply voltage MBVCC is on. That is, the wake-up interrupt frommicrocontroller 1410 is a first input signal to the gate and the signalon IDCS bus power supply line MBVCC is a second input signal to thegate. The gate passes the wake-up interrupt, i.e., the first inputsignal, to the output line of the gate that is connected to terminalUPINT only when the second input signal is inactive. Since the voltageon IDCS bus power supply line MBVCC is off, i.e., inactive, transistor1511 passes the wake-up interrupt upstream to upstream interruptterminal UPINT. Conversely, when IDCS bus power supply voltage MBVCC ison, i.e., active, the gate blocks transmission of the wake-up interruptto upstream interrupt terminal UPINT.

Schottky diode 1527, which in this embodiment is a diode that is sold byPhillips under Part No. BAS85, prevents current drain when a downstreamperipheral device issues a wake-up interrupt, i.e., drives terminalDNINT to a logic one. Without diode 1527, both transistors 1523 and 1525would operate in their reverse mode when the signal level on terminalUPINT is forced to a logic one with power supply voltages CPUVCC andMBVCC both off, which in turn would result in current flowing onto lineCPUVCC.

When a downstream peripheral device generates a wake-up interrupt, thesignal on terminal DNINT is forced to a logic one. Invertors 1412, 1413protect MBIC 700 from latch-up caused by the wake-up interrupt onterminal DNINT from a downstream peripheral device when IDCS bus powersupply voltage MBVCC is off. Invertors 1412, 1413, which in oneembodiment are circuits sold by Toshiba under Part No. 74VHC04, cannothave diodes coupled to the power supply voltage input terminal.

The active signal on terminal DNINT drives the emitter of a PNPtransistor 1511 in wake-up interrupt pass-through circuit 1530. Thecollector of PNP transistor 1511 is connected to output terminal UPINT.The base of PNP transistor 1511 is connected by a resistor 1512, whichin this embodiment is a 10 Kohm resistor, to line MBVCC. In oneembodiment, transistor 1511 and resistor 1512 are one-half of a dual PNP10 Kohm base resistor package sold by Panasonic as Part No. XN4115.Thus, the signal on input terminal DNINT, sometimes called downstreaminterrupt terminal DNINT, is gated by the voltage level on IDCS buspower supply line MBVCC to output terminal UPINT. That is, the signal oninput terminal DNINT is a first input signal to the gate and the signalon IDCS bus power supply line MBVCC is a second input signal to thegate. The gate passes the first input signal to output line of the gatethat is connected to terminal UPINT only when the second input signal isinactive. Since the voltage on IDCS bus power supply line is off,transistor 1511 passes the wake-up interrupt upstream to upstreaminterrupt terminal UPINT.

Under normal conditions, i.e., when IDCS bus power supply voltage MBVCCis on, an active signal on terminal DNINT is passed through invertors1412 and 1413 to terminal DNINTIN of MBIC 700, and is prevented fromby-passing MBIC 700 by transistor 1511 which in this embodiment is thegate. As explained above, MBIC 700 combines the signal on terminal DNINTwith the interrupt signal from microcontroller 1410 to generate a signalon terminal UPINTOUT.

Pull-up resistor 1411 ensures conformance with IDCS bus interruptprotocols that were described above. If no peripheral device existsdownstream, the newly docked peripheral device is the last peripheraldevice and so MBIC inverts the signal on terminal DNINTIN. Thus, thelogic one signal provided through pull-up resistor 1411 does not resultin generation of an upstream interrupt. However, when a new peripheraldevice is connected to terminal DNINT, the signal on terminal DNINT ispulled low, and consequently MBIC 700 generates an upstream interrupt.

System Level Architecture

FIG. 16 is a block diagram illustrating IDCS bus 150 system levelarchitecture. Stack 1610 represents the hardware and software in busdispatch 305, while stack 1620 represents the hardware and software thatis needed in each peripheral device to use IDCS bus 150. Each componentin a stack communicates with its neighbors in the stack. To support IDCSbus 150, base station 100 includes bus dispatch hardware 1602 of busdispatch 305 that interfaces with CMOS circuitry 1601 that driveselectrical signals on IDCS bus 150 and receives electrical signals fromIDCS bus 150 in base station 100. Bus dispatch hardware 1602 includes acircuit for generating a plurality of clock rates; a first-in-first-outmemory circuit that in one embodiment includes a 16-bit FIFO memory; aDMA engine; a register set for control of DMA transfers; a register setfor control of command transfers; and a status register set. In thisembodiment, the 16-bit FIFO memory is treated as a 2-bit FIFO and a14-bit FIFO. Commands IRQ-Get and IRQ-Poll are posted to the 2-bit FIFO,i.e., the high priority slot, while all other commands are posted in the14-bit FIFO, i.e., the low priority slot. Bus dispatch hardware 1602interfaces with CMOS circuitry 1601 that physically implements the SPIprotocol, as described above.

Bus dispatch 305 also includes bus dispatch master 1603 that includescommand sequencer 1612 that implements the IDCS bus command protocoldescribed above and communicates with command thread 1623 via CMOScircuitry 1601 and 1621 and bus dispatch hardware 1602 and MBIC 1622.One embodiment of bus dispatch master 1603 is presented in MicroficheAppendix A and is incorporated herein by reference. In the embodiment ofMicrofiche Appendix A, the software is written in the C programminglanguage. The software can be compiled and linked using MacintoshProgrammer's Workshop C Complier Version 3.3 on an Apple Macintoshcomputer. The resulting executable module is preferably included in aread-only memory within base station 100. The particular computer andprogramming language are illustrative only and are not intended to limitthe invention to the particular implementation described. In view ofthis disclosure, the invention can be implemented using any computer andcomputer language that is compatible with base station 100 and theperipheral devices on IDCS bus 150.

Bus dispatch master 1603 is the master of IDCS bus 150 and the source ofall bus commands that result in data transfer. Bus dispatch master 1603triggers the creation of command sequences by command sequencer 1612 inresponse to requests from IDCS bus client 1604 and peripheral client1605, that are described below. In addition, bus dispatch master 1603constantly monitors IDCS bus 150 and initiates command sequences tohandle peripheral attachment and removal and interrupt requests (IRQs)from peripheral devices on IDCS bus 150. Bus dispatch master 1603 alsosenses and adjusts data rates to peripheral devices and enforcesisochronous data transfer when required.

Command sequencer 1612 is responsible for packaging command words intothe appropriate sequences and queuing the command words in the FIFOcircuit for transmission over IDCS bus 150. In the embodiment describedabove, there are four types of command sequences, hardware commands,software commands, command Send and command Get. Command sequencer 1612builds command words with the appropriate addresses and command codesbased on instructions from bus dispatch master 1603. Command sequencer1612 strings together these command words with data packets in specificcombinations and sequences such that they are intelligible to MBICs onIDCS bus 150 and command thread 1622 in the addressed peripheral device.

Communication with bus dispatch 305 by a peripheral client 1605 arethrough IDCS bus client 1604 that is an object of the operating systemof base station 100. While the particular operating system used in basestation 100 is not a feature of this invention, in one embodiment, theoperating system is the Magic Cap operating system that is availablefrom General Magic of Mountain View, Calif. An embodiment of the IDCSbus client 1604 suitable for use with the Magic Cap operating system isalso included in Microfiche Appendix A. IDCS bus client 1604 transfersinformation to peripheral client 1605 and receives information fromperipheral client 1605 concerning data transfer, interrupt servicing,error sequencing, and peripheral device attachment and removal.

Bus dispatch master 1603 only transmits information over IDCS bus 150 inresponse to directions from IDCS bus client 1604 that in turn is actingin response to directions from peripheral client 1605. IDCS bus client1604 also communicates information to peripheral client 1605 in responseto communication from bus dispatch master 1603. For example, when busdispatch master 1603 determines that a particular peripheral devicetransmitted an interrupt, bus dispatch master 1603 can take no action onthe interrupt. Rather bus dispatch master 1603 notifies IDCS bus client1604 which in turn notifies peripheral client 1605 that an interrupt hasbeen received. It is the responsibility of peripheral client 1605 toprovide directions to bus dispatch master 1603 via IDCS bus client 1604concerning any further transactions that are required over IDCS bus 150.Peripheral client 1605 is a subclass of IDCS bus client 1604, in thisembodiment. This object is typically stored in a peripheral ROM or canbe downloaded off a network. The location of peripheral client 1605 mustbe specified for bus dispatch master 1603.

Within each peripheral device on IDCS bus 150, a command thread 1623 ina peripheral device read-only memory controls the IDCS bus protocol forthat peripheral device. Command thread 1623 provides a uniform interfacefor data transfer, interrupt requests, and the IDCS command protocol.Command thread 1623 communicates with a peripheral thread 1624 that isthe driver within the peripheral device and so handles all peripheraldevice I/O functions and transfers data to and from command thread 1623.Command thread 1623 is fully interrupt driven and takes priority overperipheral thread 1624 for use of microcontroller resources. Peripheralthread 1624, as described more completely below, must be able to providea four-byte peripheral identification and a peripheral information blockwhen commanded to do so by bus dispatch 305.

Power-On/Wake-up Sequences

Power-on of bus dispatch 305 refers to bus dispatch 305 powering lineMBVCC. Power-on occurs either as a result of base station 100 poweringon and in the process, bus dispatch 305 turning on IDCS bus power supplyvoltage MBVCC or a self-powered peripheral waking up, as describedabove, a sleeping bus dispatch 305 and thereby triggering the power-onsequence. Any self-powered peripheral, i.e., one powered by a battery orexternal power source, can be programmed to wake-up bus dispatch 305with or without user involvement. A peripheral device such as a keyboardcould be programmed to wake-up bus dispatch 305 when the user pressesone of the keys. A pager might be programmed to wake-up bus dispatch 305and alert the user when a message is received. In each case, a circuitsimilar to that illustrated in FIG. 15 is used with the microcontrollerin the peripheral device to issue a wake-up interrupt to bus dispatch305.

Wake-Up Sequence

One embodiment of wake-up sequence 601 is illustrated in FIG. 17. In buspowered step 1701, a peripheral device samples IDCS bus power supplyvoltage MBVCC. If IDCS bus power supply voltage MBVCC is active, wake-upsequence 601 terminates in end step 1705. Conversely, if IDCS bus powersupply voltage MBVCC is inactive, processing transfers from step 1701 toassert interrupt step 1702.

In step 1702, microcontroller 1410 asserts an interrupt on terminalPINTIN of MBIC 700 for a minimum of 100 nanoseconds (ns) and thendeasserts the interrupt. After deassertion of the interrupt, processingtransfers from step 1702 to step 1703.

If the interrupt is detected by bus dispatch 305, bus dispatch 305powers up IDCS bus power supply voltage MBVCC. Consequently, in step1703, microcontroller 1410 (FIG. 14) again samples IDCS bus power supplyvoltage MBVCC. If IDCS bus power supply voltage MBVCC is turned on,wake-up sequence 601 (FIG. 17) completed successfully and so processingtransfers from MBVCC test step 1703 to power-on sequence 602. In thisembodiment, if IDCS bus power supply voltage MBVCC is not turned on,processing transfers from step 1703 to step 1704. Retry step 1704 is apredetermined time delay. After the time delay expires, processingtransfers from step 1704 to step 1702. Thus, wake-up sequence 601 isperformed by a self-powered peripheral device on IDCS bus 150.

Power-On Sequence

One embodiment of power-on sequence 602 is illustrated in FIG. 18. WhenIDCS bus power supply voltage MBVCC is off, the signal level oninterrupt line MBINT is low. In apply power step 1801, bus dispatch 305turns on IDCS bus power supply voltage MBVCC and waits a minimum of fivehundred milliseconds, i.e., a sufficient time for any peripheral deviceson IDCS bus 150 to power up, before proceeding to interrupt check step1802. In apply power step 1801, the interrupt signal on line MBINT inbus dispatch 305 is set to a predetermined state, e.g., high. Recallthat when a MBIC is powered-up, i.e., voltage MBVCC is applied to theMBIC, the signal on terminal UPINTOUT is pulled low.

Thus, in interrupt check step 1802, bus dispatch 305 polls line MBINT.If the signal level on line MBINT is low, indicating that at least oneperipheral device is connected to base station 100, processing transfersfrom step 1802 to bus reset sequence 603 in bus initialization sequence620. If the signal level on line MBINT is high, no peripheral devicesare connected to base station 100 and processing transfers to step 1803.

In enable interrupt step 1803, bus dispatch 305 configures step 1802 todetect a falling edge and then returns processing to step 1802.Specifically, bus dispatch 305 enables detection of a negative edge,i.e., a transition from a logic one to a logic zero, on line MBINT instep 1802. Detection of a negative edge on line MBINT is only enabledbefore attachment of a peripheral device occurs. Once the firstperipheral device or devices are attached, detection of a signal edge online MBINT in bus dispatch 305 is disabled until address assign sequence604 and peripheral configuration sequence 605 are completed for allperipheral devices on IDCS bus 150. At that time, bus dispatch 305enables detection of a positive edge, i.e., a transition from logic zeroto logic one, on line MBINT.

Processing remains in step 1802 until a peripheral device is connected,e.g., a negative edge is detected on line MBINT, or a predetermined timeinterval has passed, in which case, bus dispatch 305 returns to asleep-mode.

Bus Reset Sequence

FIG. 19 is a process flow diagram for bus reset sequence 603. Bus resetsequence 603 is performed by bus dispatch 305 in response to fourdifferent events: (i) at least one peripheral device is connected to busdispatch 305 when bus dispatch 305 performs power-on sequence 602; (ii)no peripheral devices are connected to bus dispatch 305 when busdispatch performs power-on sequence 602, but at least one peripheraldevice is attached to bus dispatch 305 after line MBVCC is powered inpower-on sequence 602; (iii) a peripheral device performs wake-upsequence 601; and (iv) IDCS bus 150 is reset with at least oneperipheral device attached after an error is detected, or a peripheraldevice detachment occurs.

In reset bus step 1901, bus dispatch 305 toggles the voltage on lineMBVCC. In this embodiment, bus dispatch 305 turns the voltage off for250 milliseconds and then turns the voltage on for 500 milliseconds.Toggling IDCS bus power supply voltage MBVCC resets IDCS bus 150 andinitializes each peripheral device to its power-on state. Specially step1901 brings each MBIC in an attached peripheral device to power-on state800. Processing transfers from reset bus step 1901 to interrupt checkstep 1902.

In interrupt check step 1902, bus dispatch 305 polls line MBINT todetermine the signal level on line MBINT and not a transition on lineMBINT. Initially, if the signal level on line MBINT is low indicatingthat at least one peripheral device is connected to base station 100,processing transfers from step 1902 to assign address sequence 604. Ifthe signal level on line MBINT is high, no peripheral devices Areconnected to base station 100 and processing transfers to step 1903.

In enable interrupt step 1903, bus dispatch configures step 1902 todetect a falling edge and then returns processing to step 1902.Specifically, bus dispatch 305 enables detection of a negative edge,i.e., a transition from a logic one to a logic zero, on line MBINT instep 1902. Processing remains in step 1902 until a peripheral device isconnected, a negative edge is detected on line MBINT.

Address Assign Sequence

Address assign sequence 604 is triggered upon completion of bus resetsequence 603 or upon attachment of one or more downstream peripheraldevices after the peripheral devices on IDCS bus 150 have beenconfigured. During this sequence, bus dispatch 305 assigns addresses toall peripheral devices on IDCS bus 150 and ensures the MBICs in theseperipheral devices are responding properly. Peripheral device addressesare extremely important to proper functioning of IDCS bus 150. Since theMBICs are the traffic controllers on IDCS bus 150, regenerating, gating,and controlling the flow of commands and data along IDCS bus 150, it isimportant for each MBIC to know its relative position on IDCS bus 150,as explained above. The relative positioning information allows a MBICto determine how to configure the buffer circuits described above when acommand with a particular address is transmitted over IDCS bus 150.

In initialize address step 2001 (FIG. 20) of address assign sequence604, bus dispatch 305 loads a counter with starting address n foraddress assign sequence 604. The address loaded in the counter ininitialize address step 2001 depends on the event that triggered addressassign sequence 604. When address assign sequence 604 is entered frombus reset sequence 603, the counter is loaded with a value of six, inthis embodiment. When address assign sequence is entered followingattachment of a new peripheral device to IDCS bus 150 after the otherperipheral devices have been configured, i.e., from peripheralattachment sequence 609, the counter is set to the address of the newperipheral device, i.e., the address of the last peripheral device onIDCS bus 150 minus one. After the counter is loaded in step 2001,processing transfers to step 2002.

In send SOT step 2002, bus dispatch 305 transmits start of transmissioncommand SOT with the address set to seven, i.e., a global command, overIDCS bus 150. As explained above for state diagram 850, command SOTbrings the first unaddressed peripheral device on bus 150 from power-onstate 800 to no-address state 801. As explained above, when a MBICtransitions from power-on state 800 to no-address state 801, the MBICdrives the signal on line MBINT to a logic one, i.e., high. Processingtransfers from step 2002 to step 2003.

In interrupt check step 2003, bus dispatch 305 checks the signal levelon line MBINT. This is an important check because if a peripheral deviceis not attached to base station 100, the bus connector of base station100 is not properly terminated. Consequently, in the absence of anattached peripheral device, an electrostatic discharge could havetriggered the initial interrupt signal on line MBINT. Since the busconnector is not properly terminated, bus dispatch 305 is designed toensure that no commands are sent out unless at least one peripheraldevice is attached. Thus, if the signal level on line MBINT is high,processing transfers from interrupt check step 2003 to assign addressstep 2004. If the signal level on line MBINT is low, a bus error hasoccurred and so processing transfers to bus error step 2005. In buserror step 2005, IDCS bus 150 is reset and an error condition isreturned.

In assign address step 2004, bus dispatch 305 builds and sends commandAssign Address with an address of n. As explained above, in response tocommand Assign Address, the state machine in MBIC 700 that is inno-address state 801 transitions from no-address state 801 to last-idlestate 803 and the interrupt is removed from line MBINT. As explainedabove, when MBIC 700 is in last-idle state 803, bus dispatch 305 hasterminated IDCS bus 150 so that no signals are transmitted downstreamfrom that peripheral device until bus dispatch 305 confirms that anotherperipheral device is connected downstream. Processing transfers fromassign address step 2004 to set peripheral power-on step 2006.

In set peripheral power-on step 2006, bus dispatch 305 builds and sendscommand Power-on with an address n. The response of MBIC 700 to commandPower-on was described above. Step 2006 could be eliminated from addressassign sequence 604, but inclusion of step 2006 assures that theperipheral device at address n is powered-up and able to respond tocommands from bus dispatch 305. It is possible that the peripheraldevice could be off, even though IDCS bus 150 is powered-up. MBIC 700supports this command and so it is up to the developer of the peripheraldevice to decide whether to implement a response to the power-oncommand.

Step 2006 completes the address assign sequence for peripheral device ataddress n, but there may be additional peripheral devices attached toIDCS bus 150 that are in power-on state 800. Consequently, uponcompletion of step 2006, check interrupt step 2007 polls line MBINT todetermine the state of the signal on that line. If the signal on lineMBINT is low, all peripheral devices on IDCS bus 150 have been assignedaddresses and so processing transfers to peripheral configurationsequence 605 after a 500 millisecond delay. Conversely, it the signal online MBINT is high, one or more peripheral devices are attached to IDCSbus 150 that have not been assigned addresses and so processingtransfers from step 2007 to step 2008.

In assign mid-peripheral step 2008, bus dispatch 305 builds and sendscommand Assign Mid-Peripheral with an address n. In response to commandAssign Mid-Peripheral, MBIC 700 transitions from last-idle state 803 tomid-idle state 802. As explained above, in mid-idle state 802, MBIC 700enables the downstream bus drivers and configures interrupt circuit 770so that interrupts from downstream peripheral devices are no longerinverted. Thus, step 2008 configures MBIC 700 so that bus dispatch 305can communicate with the downstream peripheral device. Upon completionof step 2008, processing transfers to adjust address step 2009.

In adjust address step 2009, the value of the counter in decremented sothat the counter has the address for the next peripheral device on IDCSbus 150. Adjust address step 2009 checks the new address to determine ifthe address is less than one. If the address is less than one, a buserror is generated. After the address for the next peripheral device onIDCS bus 150 is generated and checked in step 2009, processing returnsto step 2002.

Steps 2002 through 2007 are then repeated. If check interrupt step 2007detects that the signal on line MBINT is still high, steps 2008 and 2009are repeated and processing returns to step 2002. This sequencecontinues until the signal on line MBINT is low in step 2007 and theprocessing transfers to peripheral configuration sequence 605 after a500 millisecond delay. Thus, each peripheral device on IDCS bus 150 isassigned an address before any peripheral device is configured foroperation on IDCS bus 150.

Peripheral Configuration Sequence

FIG. 21 is a process flow diagram for peripheral configuration sequence605. Peripheral configuration sequence 605 includes three sub-sequences,get peripheral ID sequence 2102, locate peripheral client sequence 2103,and attach peripheral client sequence 2104, that are performedsequentially by bus dispatch 305 for each addressed peripheral device onIDCS bus 150 during bus initialization sequence 620. During sequence605, bus dispatch 305 requests identification and peripheral informationfrom for each newly addressed peripheral device on IDCS bus 150. Busdispatch 305 also locates and attaches a peripheral client for each ofthe newly addressed peripheral devices. The information procured tellsbus dispatch 305 how to refer to the peripheral device and the speeds atwhich bus dispatch 305 can send commands and data to the peripheraldevice as well as important peripheral device requirements like thefrequency of interrupt servicing required during isochronous datatransfers.

Prior to considering these sub-sequences in further detail, the contentof a peripheral information block that is utilized in peripheralconfiguration sequence 605 is considered. A peripheral information blockis stored in non-volatile memory on-board each peripheral device. Thecommand thread in the peripheral device in response to commandsdiscussed in the following sequences retrieves information from theperipheral information block and sends that information to bus dispatch305.

The peripheral information block contains basic information about theperipheral device and may include one or more peripheral clients thatcan service the peripheral device. Multiple peripheral clients may beincluded to enable peripheral device operation on different platforms,operating systems, etc. Bus dispatch 305 uses the information in theperipheral information block to set data rates and command rates to theperipheral device. The peripheral information block also tells busdispatch 305 the percentage of bus bandwidth and the frequency ofinterrupt servicing the peripheral device requires in real-time and/orisochronous data transfer mode. In addition, the peripheral informationblock tells bus dispatch 305 how much power the peripheral device drawsfrom IDCS bus power supply voltage MBVCC, enabling proper gauging of thepower requirements of peripheral devices on IDCS bus 150.

One embodiment of the information in peripheral information block ispresented in TABLE V.

                  TABLE V                                                         ______________________________________                                        Peripheral Information Block                                                  ATTRIBUTE                                                                     BYTE LENGTH     DESCRIPTION                                                   ______________________________________                                        PInfo Length    Length of Peripheral                                          2 bytes, MSB first                                                                            Information Block not                                                         including PInfo Length bytes                                                  but including PInfo Checksum                                                  bytes.                                                        Peripheral ID   Peripheral client                                             4 bytes, zero fill                                                                            identification. Used for                                                      finding client that can                                                       service the peripheral device.                                Magicbus Version                                                                              Minimum version of ICDS bus                                   1 byte          150 required by peripheral                                                    device.                                                       Peripheral Hardware                                                                           For manufacturer use.                                         Version                                                                       1 byte                                                                        Peripheral Software                                                                           For manufacturer use.                                         Version                                                                       1 byte                                                                        Peripheral Flags                                                                              Used to convey peripheral                                     1 byte:         power source information:                                     Bits 0 thru 4 = powered by external power,                                    reserved        battery, or ICDS bus 150 for                                  Bit 5 =         everything except the MBIC                                    Peripheral may be                                                                             which is powered by IDCS bus                                  powered by      power at all times.                                           external power.                                                               Bit 6 = Peripheral                                                            may be powered by                                                             battery.                                                                      Bit 7 = Peripheral                                                            may be powered by                                                             IDCS bus power.                                                               Maximum Send    Highest command byte clocking                                 Frequency Command                                                                             frequency that the peripheral                                 4 bytes (hertz), MSB                                                                          device can handle when                                        first           receiving commands.                                           Minimum Send Delay                                                                            Minimum time from the end of                                  Per Command Word                                                                              the second byte of the command                                4 bytes         word to the start of the                                      (nanoseconds)   following command or first                                                    data byte (for sends).                                        Maximum Send    Highest data byte clocking                                    Frequency Data  frequency that the peripheral                                 4 bytes         device can handle when                                        (nanoseconds), MSB                                                                            receiving data (may be                                        first           different from commands since                                                 data may go to a FIFO rather                                                  than a microprocessor port).                                  Minimum Send Delay                                                                            Packet service rate -- time                                   Per Data Byte   peripheral device needs                                       4 bytes         between bytes in a data                                       (nanoseconds), MSB                                                                            transfer.                                                     first                                                                         Minimum Get     Minimum data byte clocking                                    Frequency Data  frequency that the peripheral                                 4 bytes         device uses to send commands                                  (nanoseconds), MSB                                                                            and data to base station 100.                                 first           This helps bus dispatch 305                                                   determine maximum time                                                        required for the peripheral                                                   device to make a transfer.                                    Maximum Get Delay                                                                             Maximum time peripheral device                                Per Data Byte   delays between bytes in a data                                4 bytes         transfer.                                                     (nanoseconds), MSB                                                            first                                                                         Maximum IRQ Latency                                                                           Maximum time delay between                                    4 bytes         interrupt assertion and                                       (nanoseconds), MSB                                                                            servicing such that peripheral                                first           device does not lose data when                                                in real-time mode. For                                                        peripheral devices operating                                                  in real time mode, the value                                                  should be as long as the                                                      peripheral device can tolerate                                                to allow for operation of                                                     other peripheral devices.                                     Maximum Transaction                                                                           The longest time required to                                  Time            complete a bus transaction                                    4 bytes         (SEND, GET packet size) for a                                 (nanoseconds)   peripheral device. The value                                                  is calculated based on nine                                                   bit times per byte plus inter                                                 character delay to compensate                                                 for possible variances between                                                actual versus requested trans-                                                mission rates. This time is                                                   the greater of: a) For the                                                    largest GET DATA block (not                                                   including PInfo Block or Per-                                                 ipheral Client download): Com-                                                mand GET DATA + bytes and delay                                               for two SOT commands and two                                                  EOT commands + each data byte                                                 with delay + other peripheral                                                 device overhead + EOT command                                                 from bus dispatch 305(100 μs);                                             OR b) For largest SEND DATA                                                   block: Command Send Data + each                                               data byte with delay + one EOT                                                command byte from bus dispatch                                                305. The actual transaction                                                   may take longer due to bus                                                    dispatch overhead.                                            Maximum Bus     Maximum time within each                                      Utilization Interval                                                                          Maximum Bus Utilization Period                                4 bytes         utilized by the peripheral                                    (nanoseconds), MSB                                                                            device. This is the total of                                  first           all the transactions that may                                                 be done by the peripheral                                                     device within the Maximum Bus                                                 Utilization Period. An                                                        overhead of 500 μs per bus                                                 dispatch command and 500 μs                                                for command IRQ Poll must be                                                  included or added by the                                                      client. Nine bit times                                                        instead of eight bit times is                                                 used in calculating the time                                                  for transmitting data to the                                                  peripheral device at the                                                      maximum rate specified by the                                                 peripheral device (assuming                                                   14.7456 MHz overall maximum                                                   clocking). This interval is                                                   always greater than or equal                                                  to Maximum Transaction Time.                                  Maximum Bus     The frequency period of the                                   Utilization Period                                                                            bus utilization by the                                        4 bytes         peripheral device. The                                        (nanoseconds), MSB                                                                            longest time period in                                        first           nanoseconds within which the                                                  peripheral device can utilize                                                 no more than the Maximum Bus                                                  Utilization Interval worth of                                                 time for bus transactions.                                                    This period is always greater                                                 than or equal to Maximum Bus                                                  Utilization Interval.                                         Maximum MBVCC   Maximum IDCS bus Vcc Current                                  Current         Drawn by the peripheral                                       4 bytes (in μA)                                                                            device.                                                       Typical MBVCC   Average IDCS bus Vcc Current                                  Current         Drawn by the peripheral                                       4 bytes (in μA)                                                                            device.                                                       Quiescent MBVCC Idle IDCS bus Vcc Current                                     Current         Drawn by the peripheral device                                4 bytes (in μA)                                                                            when in its quiescent state.                                  Reserved        Reserved for future use.                                      16 bytes (zeroed)                                                             Peripheral Name Name of the peripheral device.                                Pascal string                                                                 Peripheral Type Type or function of the device                                Pascal string   (printer, scanner, etc.)                                      Peripheral      Company name.                                                 Manufacturer                                                                  Pascal string                                                                 CLIENT PACKAGES Specifies client packages that                                Any number      can be uploaded to base                                       (including zero) of                                                                           station 100 for handling the                                  the following Client                                                                          peripheral device. Presumes                                   Package Groups: client software is not located                                                on base station 100.                                          Client Info Length                                                                            Number of bytes not including                                                 this byte used to describe                                                    this client package. (Number                                                  of bytes to skip to the next                                                  package.)                                                     Client Package Code                                                                           Type of Client (e.g. Magic                                    Type            Cap, Intel, . . . )                                           1 byte (Magic Cap =                                                           1)                                                                            Client Package Code                                                                           Sub-type of Client (e.g.                                      Sub Type        68000, MIPS, Script, . . . ).                                 1 byte (68000 =                                                               1)                                                                            Client Package  Revision number of peripheral                                 Version         driver software to be up-                                     1 byte          loaded to bus dispatch 305.                                   Client Package Size                                                                           Size of Peripheral Client                                     4 bytes, MSB    driver for peripheral device                                  first                                                                         Client Package Name                                                                           Name of the client class.                                     Pascal string                                                                 PInfo Checksum  All bytes of Peripheral Packet                                2 bytes, MSB first                                                                            added together + 1 (not                                                       including checksum)                                           ______________________________________                                    

Bus dispatch 305 begins peripheral configuration sequence 605 ininitialize address step 2101 (FIG. 21) by setting an address counter tothe address for the first unconfigured peripheral device on IDCS bus150. Again, the address is different depending on how assign addresssequence 604 was triggered. After step 2101 is completed, processingtransfers to get peripheral ID sequence 2102 that is illustrated in moredetail in FIG. 22.

In Request ID step 2201 of get peripheral ID sequence 2102, bus dispatch305 forms and transmits command Request ID to the peripheral devicehaving an address equal to the value of the address counter. Recall thatcommand Request ID instructs the command thread in the peripheral deviceto send back the four byte peripheral ID in response to the next commandGet. Upon completion of step 2201, processing transfers step 2202.

In get data step 2202, bus dispatch 305 forms and transmits command Getto the peripheral device having an address equal to the value of theaddress counter. In response to command Get, the peripheral device sendsback the information in field peripheral ID of the peripheralinformation block. (See Table V).

The information is received by bus dispatch 305 in receive ID step 2203.The four bytes received are a unique identification for the driver,sometimes called a peripheral client, of the peripheral device. When endof transmission command EOT is received from the peripheral deviceindicating that the data transmission is complete, bus dispatch 305responds with an end of transmission command EOT and processingtransfers from step 2203 to locate peripheral client sequence 2103.

In locate client sequence 2103, which is illustrated in more detail inFIG. 23, bus dispatch 305 uses the peripheral ID information to find theclient that can service the peripheral device. In sequence 2103, busdispatch 305 tries to locate an installed client in memory of basestation 100 and if an installed client is not found, to download theclient from the peripheral device. Once a client is found, bus dispatch305 proceeds to attach the client. If a client is not found, busdispatch 305 alerts the user with an error message.

Specifically, in client in base station check step 2301, bus dispatch305 performs a sequential search through a client table within a memoryof base station 100 for an installed client that services peripheraldevices with the peripheral ID of the peripheral device at address n. Ifa match is found between an entry in the client table and the peripheralID, a client for the peripheral device has been located and soprocessing transfers to peripheral client attach sequence 2104 andconversely to load peripheral client sequence 2302, that is illustratedin more detail in FIG. 24.

As explained more completely below, in load peripheral client sequence2302, bus dispatch 305 tries to download a driver from the peripheraldevice. Bus dispatch 305 requests and searches through the peripheraldevice's peripheral information block to determine whether the blockcontains any peripheral clients and if so, whether any of the peripheralclients are compatible with base station 100. If such a peripheralclient is found, bus dispatch downloads the peripheral client from theperipheral device to base station 100. Upon completion of loadperipheral client sequence 2302, processing transfers to a second clientcheck 2303 in locate peripheral client sequence 2103.

If a driver is not found in the peripheral device, processing transfersfrom check step 2303 to bus error step 2304. Conversely, if a driver wasfound in step 2303, bus dispatch 305 confirms that the driver wassuccessfully downloaded and that the driver can service the peripheraldevice. If these requirements are true, processing transfers from step2303 to attach peripheral client sequence 2104 and otherwise to buserror step 2304. Bus error step 2304 informs the user that theperipheral device can not be used without identification of the locationof a suitable driver. In such a case, the user may be able to download adriver to base station 100 from a remote location.

The specific operations performed in load peripheral client sequence2302 are illustrated in FIG. 24. In get Pinfo step 2401, bus dispatch305 transmits command Get Peripheral Info to the peripheral device atthe address on IDCS bus 150 equal to the value of the address counter.Recall that command Get Peripheral Info instructs the peripheral deviceto send its peripheral information block to bus dispatch 305 uponreceipt of the next command Get. Upon completion of step 2401,processing transfers to get data step 2402 in which bus dispatch 305sends command Get to retrieve the requested data from the addressedperipheral device.

In step 2403, bus dispatch 305 initializes a client location counter toa first predetermined value, which in this embodiment is one and thenprocessing transfers to the loop of steps defined by steps 2404 to 2406.Bus dispatch 305 in this loop performs a sequential search through theclient packages (if any) in the peripheral information block to see ifthere is a peripheral client that is compatible with base station 100.

Specifically, in client in Pinfo check step 2404, bus dispatch 305checks to determine whether the check sum at the end of the peripheralinformation block has been reached. If the check sum is detected,processing transfers from step 2404 to bus error step 2407. Bus errorstep 2407 informs the user that the peripheral device can not be usedwithout identification of the location of a suitable driver. If thecheck sum is not detected processing transfers from step 2404 to step2405.

In step 2405, bus dispatch 305 compares the information defining theperipheral client in the client package at the location pointed to bythe client location counter with the capabilities of base station 100.If the peripheral client is compatible with base station 100 processingtransfers to decrement counter step 2408 and otherwise to incrementcounter step 2406.

Increment counter step 2406 increments the client location counter andreturns processing to step 2404 that checks to determine whether thereis another client package in the peripheral information block and thento step 2405.

When processing transfers to step 2408, a compatible peripheral clienthas been found in the peripheral device and bus dispatch 305 mustdownload that peripheral client. Thus, in step 2408, bus dispatch 305decrements client location counter and transfers processing to getclient step 2409.

In get client step 2409, bus dispatch 305 sends command Get Driver tothe peripheral device having an address on IDCS bus 150 equal to thevalue of the address counter. Processing transfers from step 2409 tocheck counter step 2410. In step 2410, if the value of the clientlocation counter is zero, processing transfers to step 2411 andotherwise to step 2408. Thus, if one of the clients in the peripheralinformation block is compatible with bus dispatch 100, bus dispatch 305sends out a series of get driver commands where the number of commandsis equal to the value of the client location counter which is just theposition of the peripheral client in the group of peripheral clients.For example, if the first client in the group was compatible, the valueof the client location counter would equal zero after the first getdriver command was sent. If the fourth client in the group wascompatible, the value of the client location counter would equal threeafter the first get client command was sent. In this case, bus dispatch305 sends out three more get client commands (or a total of 4) beforethe client location counter reaches a value of zero.

When the value of the client location counter equals zero and processingtransfers from step 2410 to 2411, bus dispatch 305 sends out command Getto retrieve the peripheral client from the peripheral device. When theperipheral client has been received by bus dispatch 305, processingreturns to step 2303, that was described above.

If a peripheral client is located in base station 100 or down loadedfrom the peripheral device, bus dispatch proceeds to attach the clientthrough attach peripheral client sequence 2104 that is illustrated inmore detail in FIG. 25.

During attach peripheral client sequence 2104, bus dispatch 305transfers control of IDCS bus 150 temporarily to the peripheral clientand responds to directives from the peripheral client. The peripheralclient initiates all commands in this sequence and self-configures withassistance from bus dispatch 305. As a result, FIG. 25 shows thesequence from the perspective of the peripheral client, and not busdispatch 305 as in the other figures that illustrate the operation ofbus dispatch 305.

The sequence illustrated in FIG. 25 is the minimum series of commands aperipheral client performs in attach peripheral client sequence 2104.Clients may also perform some of their own peripheral protocol sequencesduring sequence 2104 to initialize the peripheral device.

In step 2501, the peripheral client instructs bus dispatch 305 toretrieve the peripheral information block from the peripheral device.Thus, bus dispatch 305 sends out command Get Peripheral Info in step2501 and then transfers to step 2502 that sends out command Get. Inresponse to command Get, the peripheral devices transmits the peripheralinformation block to bus dispatch 305.

When the peripheral information block is received, the peripheralclient, in update bus dispatch info step 2503, uses the information tocompute and store in bus dispatch 305 command rates, data rates, maximumfrequencies, block lengths, etc. Though two peripheral devices may sharethe same peripheral client, the capabilities of the devices may differ.Thus, the peripheral client performs these calculations to customize theperipheral client to the capabilities of a particular peripheral deviceor to the capabilities of a particular version of hardware in basestation 100. Upon completion of step 2503, processing transfers toupdate info in peripheral client step 2504 where the peripheral clientupdates its own information. Upon completion of step 2504, processingtransfers to step 2105.

In adjust address step 2105 (FIG. 21), bus dispatch 305 decrements theaddress counter and then checks, in all peripherals configured checkstep 2106, whether the value of the address counter is less than theaddress of the last peripheral device on IDCS bus 150. While the valueof the address counter is greater than or equal to the address of thelast peripheral device on IDCS bus 150, processing transfers from step2106 to get peripheral ID sequence 2102. Sequences 2102, 2103, and 2104,and step 2105 are repeated for the next peripheral device on IDCS bus150.

When all peripheral devices are configured, processing transfers fromstep 2106 (FIG. 21) to enable bus interrupt step 2107. In step 2107, busdispatch 305 enables detection of a positive edge on line MBINT andtransfers processing to service bus sequence 606.

Service Bus Sequence

Bus dispatch 305 spends most of its time cycling through service bussequence 606 where bus dispatch 305 responds to interrupts received fromperipheral devices on IDCS bus 150 and commands queued for transmissionto peripheral devices or the MBICs in the peripheral devices by theperipheral and IDCS bus clients. Bus dispatch 305 remains in waitingstep 2601 until a command or an interrupt is detected. Processingtransfers from waiting step 2601 to a first last request check step 2602in response to either an interrupt or a command. If an interrupt and acommand are received simultaneously, interrupts take priority and areserviced first as shown in FIG. 26. If an interrupt is received, servicebus sequence 606 performs the interrupt poll sequence describedpreviously. In this embodiment the interrupt poll sequence includessteps 2602 to 2611 and command sequencer 2614 that are described morecompletely below.

When service bus sequence 606 is initiated, bus dispatch 305 checks infirst last request check step 2602 to see if the last bus commandresulted in an error. This ensures that errors are detected immediatelyafter the command sequence in which they occur and are not compounded bycontinued bus activity. If an error is detected in step 2602, processingtransfers to error service sequence 2603, where bus dispatch 305processes the error, as described more completely below.

If no error is detected in step 2602, processing transfers to a secondlast request check step 2604. In step 2604, bus dispatch 305 checks tosee if the last command was command IRQ-Get. Command IRQ-Get is usedafter an interrupt polling sequence when the source of the interrupt isdetermined in response to command IRQ-Poll. Command IRQ-Get is sent tothe peripheral device that generated the interrupt to determine thenature of the interrupt.

If the last command was command IRQ-Get indicating that interruptpolling is complete, processing transfers from step 2604 to sendIRQ-Poll step 2605. In send IRQ-Poll step 2605, bus dispatch 305 sendscommand IRQ-Poll with an address of seven to re-enable interrupts onIDCS bus 150 and transfers processing to waiting step 2601.

If the last command was not command IRQ-Get, processing transfers fromstep 2604 to a third request check 2606 where bus dispatch 305 checks tosee if the last command was command IRQ-Poll, which indicates whether anInterrupt-Poll is in progress. If the last command was command IRQ-Poll,bus dispatch 305 transfers processing from step 2606 to interrupt activecheck step 2607 where bus dispatch 305 determines whether the lastperipheral device polled was the source of the interrupt.

In interrupt active check step 2607, bus dispatch 305 checks to see ifthe signal level on line MBINT is high which indicates that the lastperipheral device polled was the source of the interrupt. If the signallevel on line MBINT is high, processing transfers to send IRQ-Get step2608 and otherwise to IRQ-poll sequence 2609.

In send IRQ-Get step 2608, bus dispatch 305 posts command IRQ-Get to theperipheral device to determine the nature of the interrupt. Ifprocessing transfers to IRQ-poll sequence 2609, the last peripheraldevice polled was not the source of the interrupt and so bus dispatch305 proceeds to poll the next peripheral device as explained morecompletely below. Upon completion of either step 2608 or step 2609,processing transfers to command sequencer 2614, that is also describedmore completely below.

If third request check step 2606 does not detect that the last commandwas command IRQ-Poll, processing transfers from step 2606 to interruptcheck step 2610. In step 2610, bus dispatch 305 checks the state ofinterrupt line MBINT to determine if there is an interrupt on IDCS bus150. If the signal level on line MBINT is high, there is an interrupt onIDCS bus 150 and processing transfers from step 2610 to start IRQ-pollsequence 2611. Upon completion of start IRQ-poll sequence 2611,processing transfers to command sequencer 2614.

If the signal level on line MBINT is low, there are no interrupts onIDCS bus 150 and so processing transfers from step 2610 to command inqueue check step 2612 so that bus dispatch 305 can attend to any commandrequests that have been posted to the queue.

If no commands are in the queue, processing transfers from step 2612 tostep waiting 2601, i.e., bus dispatch 305 returns to the waiting stateand waits for an interrupt or command to occur. Conversely, if there isone or more commands in the queue, processing transfers from step 2612to get command from queue step 2613. In step 2613, bus dispatch 305takes the oldest command from the queue and transfers processing tocommand sequencer 2614. Upon completion of operations by commandsequencer 2614, bus dispatch 305 loops back through the entire servicebus sequence 606 again to catch any errors that occurred in the previouscommand cycle, to continue any interrupt polling in progress, and tohandle any commands in the queue.

Prior to considering the operation of command sequencer 2614, startIRQ-poll sequence 2611 and IRQ-poll sequence 2609 are considered. FIG.27 is a process flow diagram for start IRQ-poll sequence 2611.Initially, in disable interrupt step 2701, bus dispatch 305 disables theability to detect an edge on interrupt line MBINT. Edge detection oninterrupt line MBINT remains disabled until the source of the interruptis found and handled. Processing transfer from step 2701 to set startaddress step 2702.

In start address step 2702, bus dispatch 305 sets the start address tothe address used in the last IRQ-Get command minus one. This results ina round robin approach to IRQ polling in which the poll begins with theperipheral device immediately downstream from the last peripheral devicethat signaled an interrupt. Processing transfers from step 2702 to setcounter step 2703.

In set counter step 2703, bus dispatch 305 sets an Interrupt-Pollcounter to the start address. However, if the start address is less thanthe address of the last peripheral device on IDCS bus 150, bus dispatch305 loops back to the first peripheral device on IDCS bus 150 and setsthe Interrupt-Poll counter to address six. Processing transfers fromstep 2703 to step 2704.

In post command step 2704, bus dispatch 305 posts command IRQ-Poll tothe address specified by the value of the Interrupt-Poll counter andtransfers processing to decrement counter step 2705. In decrementcounter step 2705, bus dispatch 305 decrements the Interrupt-Pollcounter and then transfers processing to command sequencer 2614.

As explained above, if an IRQ-poll is already in progress, step 2607 inservice bus sequence 606 transfers to IRQ-poll sequence 2609 that isillustrated in more detail in FIG. 28A. At this point, bus dispatch 305has determined that an IRQ-poll is in progress and that the lastperipheral device polled was not the source of the interrupt. Beforepolling the next peripheral device on IDCS bus 150, bus dispatch 305checks in last IRQ-poll error check step 2801 whether the last IRQ-pollresulted in an error.

If an error is detected in step 2801, processing transfers to reset busstep 2802 and otherwise to counter check step 2803. In reset bus step2802, IDCS bus 150 is reset and an error message is returned. In countercheck step 2803, bus dispatch 305 determines whether the current valueof the Interrupt-Poll counter is equal to the start address that was setin step 2702. If the current value of the Interrupt-Poll counter isequal to the start address, bus dispatch 305 has polled each peripheraldevice on IDCS bus 150 without finding the source of the interrupt. Thismeans that a new peripheral device has been attached to IDCS bus 150.Thus, bus dispatch 305 transfers processing to peripheral attachmentsequence 609, that as described below, assigns an address and configuresthe new peripheral device. After the address is assigned and theperipheral device is configured, bus dispatch 305 enables edge detectionon line MBINT.

If the current value of the Interrupt-Poll counter is not equal to thestart address, processing transfers from step 2803 to post commandIRQ-Poll step 2804. In post command IRQ-Poll step 2804, bus dispatch 305posts command IRQ-Poll to the address specified by the value of theInterrupt-Poll counter and transfers processing to decrement counterstep 2805. In decrement counter step 2803, bus dispatch 305 decrementsthe Interrupt-Poll counter and then transfers processing to commandsequencer 2614.

Peripheral attachment sequence 609 is illustrated in FIG. 28B. In assignmid step 2851, bus dispatch 305 sends command Assign-Mid to the formerlast peripheral device that instructs the MBIC in the former lastperipheral device to configure itself as a mid-peripheral device. Asexplained above, this enables the downstream signal lines for the formerlast peripheral device and allows bus dispatch 305 to communicate withthe newly attached peripheral device. Upon completion of assign mid step2851, peripheral attachment sequence 609 transfers to address assignsequence 604, that was described above.

To send command IRQ-Poll, command IRQ-Get or another command to aperipheral device on IDCS bus 150, bus dispatch 305 sends the postedcommand request to command sequencer 2614 where the command is assembledand sent to IDCS bus 150. The process implemented by command sequencer2614, in this embodiment of the invention, is illustrated in FIG. 29.The process illustrated in FIG. 29 is for a configuration where theprocessor in base station 100 is shared, i.e., the processor is runningboth a user interface and bus dispatch software simultaneously.Consequently, a direct memory access engine (DMA) is used in conjunctionwith the processor. Those skilled in the art will appreciate that theprocess of assembling commands for transfer over IDCS bus as well as theactual transfer can be implemented in a wide variety of ways in view ofthis disclosure. Therefore, this embodiment is only illustrative of theprinciples of the invention and is not intended to limit the inventionto the particular embodiment discussed below.

Initially, in set bus speed step 2901 of command sequence 2614, busdispatch 305 sets the speed of IDCS bus 150 based on the type of commandor data being sent and the capabilities of the addressed peripheraldevice. Next, in a first command check step 2902, bus dispatch 305checks to see if the command request is command Get. If the commandrequest is command Get, processing transfers to step 2903 and otherwiseto step 2904.

In receive data step 2903, bus dispatch 305 sets a timer for a time outbased on the information provided in the peripheral information blockfor the addressed peripheral device. Bus dispatch 305 then sets the DMAengine to read from IDCS bus 150 and transfers processing to step 2906.

In a second command check step 2904, bus dispatch 305 checks to see ifthe command request is command Send. If the command request is commandSend, processing transfers to step 2905 and otherwise to step 2906.

In transmit data step 2905, bus dispatch 305 sets the DMA engine for awrite to IDCS bus 150 and transfers processing to step 2906. Build andoutput command sequence step 2906 builds and outputs the commandsequence for the appropriate command and then returns processing to step2602 where processing proceeds as describe above.

Error service sequence 2603 is illustrated in more detail in FIG. 30.Bus dispatch 305 distinguishes errors caused by peripheral devicedetachments from other types of errors, even though, in this embodiment,the response is the same. Bus dispatch 305 resets IDCS bus 150 in bothcases. However, in another embodiment, a different response can beprovided for a peripheral device detachment.

Specifically, in last request check step 3001, bus dispatch 305 checksto see if the last command prior to detection of the error was commandIRQ-Get. If the last command prior to detection of the error was commandIRQ-Get, the error indicates no response was obtained from theperipheral device in response to the command IRQ-Get. This indicatesthat a peripheral device was detached from IDCS bus 150 and soprocessing transfers from step 3001 to peripheral detachment sequence608 which in turn passes directly to bus reset sequence 603.

If the last command prior to detection of the error was not commandIRQ-Get, processing transfers from step 3001 to reset bus step 3002. Inthis embodiment, reset bus step 3002 simply transfers processing to busreset sequence 603.

Thus, when a peripheral device is detached, the peripheral deviceimmediately upstream from the disconnection generates an interrupt tobus dispatch 305. Bus dispatch 305 starts an IRQ-poll sequence asillustrated in FIGS. 26 and 27. If the start address for the IRQ-pollsequence is for a peripheral device downstream from the last peripheraldevice left on IDCS bus 150 after the disconnection, the disconnectionis detected by the first command IRQ-Get because the interrupt signal isactive after the first command IRQ-Poll.

Conversely, if the start address for the IRQ-poll sequence is for eithera peripheral device upstream from the last peripheral device left onIDCS bus 150 after the disconnection or the last peripheral device lefton IDCS bus 150 after the disconnection, the disconnection is detectedonly when command IRQ-Get is sent to the peripheral device addressimmediately downstream from the last peripheral device left on the bus.

IDCS Bus Timing

FIG. 31A shows the waveform timing that applies to signals on line MBCLKunder normal data transmissions. FIG. 31B shows the waveform timing thatapplies between signals on lines MBCLK and MBDATA. Table VI defines thevarious times represented by reference numerals in FIGS. 31A and 31B.

                  TABLE VI                                                        ______________________________________                                        SERIAL PERIPHERAL INTERFACE TIMING                                            Symbol Parameter  Conditions                                                                             Min    Max   Unit                                  ______________________________________                                        fmax   Maximum             0.5    14.75 MHz                                          clock                                                                         frequency                                                              Tper   Clock period                                                                             See      67.8   2000  ns                                                      FIG. 31A                                                    Tlo    Clock low  See      20           ns                                           pulse width                                                                              FIG. 31A                                                    Thi    Clock high See      20           ns                                           pulse width                                                                              FIG. 31A                                                    Tr     Rise time  See             10    ns                                                      FIG. 31A                                                    Tf     Fall time  See             10                                                            FIG. 31A                                                    tsu    Set-up time                                                                              See      15           ns                                                      FIG. 31B                                                    thold  Hold time  See      15           ns                                                      FIG. 31B                                                    ______________________________________                                    

The particular cables and connectors used with this invention are notcritical to the invention. Nevertheless, in one embodiment, the hardwarelisted in Table VII is used.

                  TABLE VII                                                       ______________________________________                                        Honda Connectors                                                                             Part                                                           Honda Part #   Description   Application                                      ______________________________________                                        HDR-EA14LMY ( ) G1-SL                                                                        14-pin Male   Base station                                                    connector with                                                                              Serial                                                          Latching Pins Connector,                                                                    Peripheral                                                                    Downstream                                                                    Serial                                                                        Connector                                        HDR-EA14LFY ( ) G1-SL                                                                        14-pin Female Peripheral                                                      connector with                                                                              Upstream                                                        Latching Pins Serial                                                                        Connector                                        HDR-EA14LFY ( ) G1                                                                           14-pin Female Docking                                                         connector w/o Peripheral Up-                                                  Latching Pins stream Serial                                                                 Connector                                        HDR-EA14M ( ) G1                                                                             14-pin Male   Cable                                                           Cable connector                                                HDR-EA14F ( ) G1                                                                             14-pin Female Cable                                                           Cable connector                                                HDR-E14LPA     Cable Connector                                                                             Cable                                                           Housing with                                                                  pin grips                                                      ______________________________________                                    

Each of the connectors listed in Table VII are 14-pin connectors. Asdescribed above, IDCS bus 150 requires only a five pin connector.Nevertheless, the 14-pin connector is used on base station 100 tosupport serial communication protocols and charging capability. TableVIII lists the pin function assignments for one embodiment. Signals areoriented with respect to each other in the connectors to minimizevoltage differentials between adjacent signals and adjacent contacts, toprovide suitable pairing for twisted pair cables, and to providefirst-make, first-break connection of the ground line.

                  TABLE VIII                                                      ______________________________________                                        PIN        PIN                                                                NUMBER     NAME       FUNCTION                                                ______________________________________                                        1          Chg2-      Charge return pin. Limited to                                                 one amp charging current                                                      return. Must not be connected                                                 to ground Pin 14 within a                                                     charger.                                                2          /RTS       Passive serial bus handshaking                                                status output signal pin to                                                   serial peripheral device.                               3          /CTS       Passive serial bus handshaking                                                input status pin from serial                                                  peripheral device.                                      4          Chg1+      Charge input pin. Limited to                                                  one amp charging current.                                                     Must not be connected to                                                      ground pin 14 within a                                                        charger. Nine volt trickle                                                    nominal charging voltage, and                                                 twelve volts maximum fast                                                     charging voltage.                                       5          TxEIA      Passive serial bus data pin to                                                peripheral device.                                      6          RxEIA      Passive serial bus data pin                                                   from peripheral device.                                 7          Chg1-      Charge return pin. Limited to                                                 one amp charging current                                                      return. Must not be connected                                                 to ground pin 14 within a                                                     charger.                                                8          SP1        Spare for future expansion.                             9          MBCLK      Bidirectional bus clock pin.                            10         Power      Power pin.                                              11         MBINT      Unidirectional bus interrupt                                                  pin.                                                    12         Chg2+      Charge input pin. Limited to                                                  one amp charging current.                                                     Must not be connected to                                                      ground pin 14 within a                                                        charger. Nine volt trickle                                                    nominal charging voltage, and                                                 twelve volts maximum fast                                                     charging voltage.                                       13         MBDATA     Bidirectional bus data pin.                             14         Ground     Ground pin, passive serial bus                                                signal ground, trickle charge                                                 ground.                                                 ______________________________________                                    

Thus, as shown in FIG. 32A, five pins on the 14-pin connector arededicated to carrying a full-duplex serial interface signal set 3200with handshaking. By supplying the appropriate level shifters manydifferent types of serial interfaces including RS-232 and RS-422configurations may be implemented using these pins. The serial interfacesignals are accessed only at a base station 100 or a docking unitconnector, as these signals are not carried through the multiconnectionassembly cable of this invention since serial communications are notdaisy-chainable.

Power (VCC) and ground are carried on pins 10 and 14, respectively. Thispin pair is used for both the RS232 and RS422 level shifters. Themaximum allowable current on each terminal is 5 milliamps. Signals RxEIAand TxEIA on pin 6 and 5, respectively, are the respective input andoutput signal terminals for transmitting and receiving data from aserial peripheral. Signal RTS on pin 2 and signal CTS on pin 3 providethe output and input handshaking status signals to and from a serialdevice.

The serial interface terminals for communicating with the serial deviceare CMOS logic level interface pins and share the same electriccharacteristics as described below for the IDCS bus 150 pins.Commercially available components for RS232 and RS422 interfaces includethe Maxim 231 single supply RS232 level shifter, and the NationalDS34C86 receiver and CS34C87 transmitter, respectively.

Charging pin set 3210, as illustrated in FIG. 32B, includes four pins asdescribed in Table 4. These pins support all battery charging, bothtrickle and fast charge modes.

IDCS bus signals are carried by three pins, MBDATA, MBCLK, and MBINT(FIG. 32C). The IDCS bus protocol also uses pins Power and Ground. Aspare pin, pin 8, is provided for future expansion and is implemented inall peripheral devices and cables, in one embodiment.

The following table indicates the DC operating range for IDCS bus 150.

                  TABLE IX                                                        ______________________________________                                        Magicbus Electrical                                                           Specifications (@ T = 25° C.)                                          Symbol                                                                              Parameter Conditions                                                                              Min    Max     Unit                                 ______________________________________                                        Vih   High-     See Note  0.7 Vcc                                                                              Vcc + 0.3                                                                             V                                          level     (1)                                                                 input                                                                         voltage                                                                 Vil   Low-level           -0.3   0.3 Vcc V                                          input                                                                         voltage                                                                 Voh   High-     See Note  0.8 Vcc                                                                              Vcc     V                                          level     (2)                                                                 output                                                                        voltage                                                                 Vol   Low-level           0      0.2 Vcc V                                          output                                                                        voltage                                                                 Ii    Input     Vi = Vcc  -10    10      μA                                      leakage   or GND                                                              current                                                                 Ioz   Tri-state Vo = Vcc  -40    40      μA                                      output    or GND                                                              current                                                                 Icca  Supply    Vi = Vcc         5       mA                                         current   or GND                                                              (active)                                                                Iccs  Supply    Vi = Vcc         100     μA                                      current   or GND                                                              (standby)                                                               ______________________________________                                         (1) Input buffers are CMOS, not TTL.                                          (2) Output buffers should be TTL output buffers, but capable of swinging      to a full Vcc and completely down to GND (all the way to both power suppl     rails).                                                                       (3) The source and sinking current are 2.4 mA DC for signals on lines         MBCLK, MBDATA, and MBINT.                                                

This application is related to the following commonly assigned andcommonly filed U.S. patent applications: 1. Ser. No. 08/XXX,XXXentitled: "An Intelligent Low Power Serial Bus", Walter F. Broedner,Anthony M. Fadell, Steven G. Perlman and John E. Watkins; 2. Ser. No.08/XXX,XXX entitled: "A Method For Configuring an Intelligent Low PowerSerial Bus", Anthony M. Fadell and Walter F. Broedner; 3. Ser. No.08/XXX,XXX entitled: "A Bus Interface Circuit For An Intelligent LowPower Serial Bus", Walter F. Broedner and Anthony M. Fadell; and 4. Ser.No. 08/XXX,XXX entitled: "Support Structures For An Intelligent LowPower Serial Bus", Walter F. Broedner and Anthony M. Fadell.

The above embodiments of this invention are illustrative only and arenot intended to limit the invention to the particular embodimentsdescribed. In view of this disclosure, those skilled in the art canutilize the IDCS bus architecture and SPI protocol in a wide variety ofapplications. The low power intelligent bus configuration of thisinvention that supports a wide variety of peripheral devices at variousbus speeds provides a new capability in serial bus performance.Moreover, the uniform interface that is independent of the peripheraldevice type permits inclusion of low volume peripheral devices on a buswithout incurring the cost of developing a peripheral device specificinterface. These and the other advantages described above eliminate thecomplexity associated with prior art serial bus structures.

We claim:
 1. A method for sending data and commands to and receivingdata from peripheral devices connected to a base station by a serial buscomprising:configuring each peripheral device on said serial bus toreceive data and clock signals from said base station in an idle mode ofoperation; and maintaining said idle mode configuration for allperipheral devices on said serial bus between said base station and anaddressed peripheral device upon a command send being transmitted oversaid serial bus by said base station.
 2. A method for sending data andcommands to and receiving data from peripheral devices connected to abase station by a serial bus as in claim 1 furthercomprising:reconfiguring an addressed peripheral device and allperipheral devices, on said serial bus between said addressed peripheraldevice and said base station, to transmit clock and data signals fromsaid addressed peripheral device to said base station wherein saidreconfiguring is performed upon said addressed peripheral devicereceiving a command to transmit data to said base station.
 3. A methodfor sending data and commands to and receiving data from peripheraldevices connected to a base station by a serial bus as in claim 2wherein each peripheral device includes upstream buffers coupled to saidserial bus, downstream buffers coupled to said serial bus, andperipheral device buffers coupled to said upstream buffers; and furtherwherein reconfiguring said addressed peripheral device and allperipheral devices on said serial bus between said addressed peripheraldevice and said base station further comprises:reconfiguring downstreambuffers in a peripheral device connected directly to said base stationby said serial bus so that clock and data signals can be received fromanother peripheral device on said serial bus.
 4. A method for sendingdata and commands to and receiving data from peripheral devicesconnected to a base station by a serial bus as in claim 3 whereinreconfiguring said addressed peripheral device and all peripheraldevices on said serial bus between said addressed peripheral device andsaid base station further comprises:reconfiguring upstream anddownstream buffers in all peripheral devices on said serial bus betweensaid addressed peripheral device and said peripheral device connecteddirectly to said base station by said serial bus so that the downstreambuffers pass clock and data signals to the upstream buffers.
 5. A methodfor sending data and commands to and receiving data from peripheraldevices connected to a base station by a serial bus as in claim 4wherein reconfiguring said addressed peripheral device and allperipheral devices on said serial bus between said addressed peripheraldevice and said base station further comprises:reconfiguring upstreamand peripheral buffers in said addressed peripheral device so that theperipheral buffers pass clock and data signals to the upstream buffers.6. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 4 wherein reconfiguring said addressed peripheral device and allperipheral devices on said serial bus between said addressed peripheraldevice and said base station further comprises:issuing a start oftransmission command by said addressed peripheral device wherein inresponse to said start of transmission command, said downstream buffersin said peripheral device connected directly to said base station bysaid serial bus are coupled to said upstream buffers so that thedownstream buffers pass clock and data signals to the upstream buffers.7. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 6 further comprising:transmitting clock and data signals from saidaddressed peripheral device to said base station over said serial bus.8. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 7 further comprising:reconfiguring said addressed peripheraldevice and all of said peripheral devices on said serial bus betweensaid addressed peripheral device and said base station, upon saidaddressed peripheral device transmitting an end of transmission command.9. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 8 wherein reconfiguring said addressed peripheral device and allof said peripheral devices on said serial bus between said addressedperipheral device and said base station, upon said addressed peripheraldevice transmitting an end of transmission command furthercomprises:reconfiguring upstream and downstream buffers in allperipheral devices on said serial bus between said addressed peripheraldevice and said base station so that the upstream buffers pass clock anddata signals to the downstream buffers.
 10. A method for sending dataand commands to and receiving data from peripheral devices connected toa base station by a serial bus as in claim 9 furthercomprising:reconfiguring said addressed peripheral device so that theupstream buffers pass clock and data signals to the downstream buffersupon said base station transmitting an end of transmission command. 11.A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial buscomprising:configuring each peripheral device on said serial bus betweensaid base station and a last peripheral device on said serial bus in amid-idle mode of operation wherein in said mid-idle mode of operation, aperipheral device receives data and clock signals from said base stationand passes said data and clock signals to another peripheral device onsaid serial bus; and configuring said last peripheral device in alast-idle mode of operation wherein in said last-idle mode, said lastperipheral device receives data and clock signals from said base stationand blocks transmission of said data and clock signals from furthertransmission over said serial bus.
 12. A method for sending data andcommands to and receiving data from peripheral devices connected to abase station by a serial bus as in claim 11 wherein each peripheraldevice includes upstream buffers coupled to said serial bus, downstreambuffers coupled to said serial bus, and peripheral device bufferscoupled to said upstream buffers and further wherein configuring eachperipheral device on said serial bus between said base station and saidlast peripheral device on said bus in a mid-idle mode of operationfurther comprises:coupling said upstream buffers to said downstreambuffers; and disabling said peripheral device buffers.
 13. A method forsending data and commands to and receiving data from peripheral devicesconnected to a base station by a serial bus as in claim 12 whereinconfiguring said last peripheral device on said bus in a last-idle modeof operation further comprises:disabling said downstream and saidperipheral device buffers.
 14. A method for sending data and commands toand receiving data from peripheral devices connected to a base stationby a serial bus as in claim 12 further comprising:transmitting a commandsend over said serial bus by said base station wherein said command sendincludes an address for one peripheral device on said serial bus.
 15. Amethod for sending data and commands to, and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 14 further comprising:reconfiguring upstream buffers of said oneperipheral device having said address so that said upstream buffers ofsaid one peripheral device are coupled to said peripheral device buffersof said one peripheral device.
 16. A method for sending data andcommands to and receiving data from peripheral devices connected to abase station by a serial bus as in claim 15 furthercomprising:transmitting data from said base station to said oneperipheral device over said serial bus.
 17. A method for sending dataand commands to and receiving data from peripheral devices connected toa base station by a serial bus as in claim 16 furthercomprising:transmitting an end of transmission command by said basestation over said serial bus upon completion of transmitting data.
 18. Amethod for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 17 further comprising:reconfiguring said one peripheral device toan idle-mode that is the same as the idle-mode of said one peripheraldevice prior to receipt of said send command.
 19. A method for sendingdata and commands to and receiving data from peripheral devicesconnected to a base station by a serial bus as in claim 13 furthercomprising:transmitting a commend get over said serial bus by said basestation wherein said common get includes an address for one peripheraldevice or said serial bus hereinafter referred to as said addressedperipheral device.
 20. A method for sending data and commands to andreceiving data from peripheral devices connected to a base station by aserial bus as in claim 19 further comprising:reconfiguring saidaddressed peripheral device and all peripheral devices, on said serialbus between said addressed peripheral device and said base station, totransmit clock and data signals from said addressed peripheral device tosaid base station.
 21. A method for sending data and commands to andreceiving data from peripheral devices connected to a base station by aserial bus as in claim 20 wherein reconfiguring said addressedperipheral device and all peripheral devices on said serial bus betweensaid addressed peripheral device and said base station furthercomprises:reconfiguring downstream buffers in a peripheral deviceconnected directly to said base station by said serial bus so that clockand data signals can be received from another peripheral device on saidserial bus.
 22. A method for sending data and commands to and receivingdata from peripheral devices connected to a base station by a serial busas in claim 21 wherein reconfiguring said addressed peripheral deviceand all peripheral devices on said serial bus between said addressedperipheral device and said base station further comprises:reconfiguringupstream and downstream buffers in all peripheral devices on said serialbus between said addressed peripheral device and said peripheral deviceconnected directly to said base station by said serial bus so that thedownstream buffers pass clock and data signals to the upstream buffers.23. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 22 wherein reconfiguring said addressed peripheral device and allperipheral devices on said serial bus between said addressed peripheraldevice and said base station further comprises:reconfiguring upstreamand peripheral buffers in said addressed peripheral device so that theperipheral buffers pass clock and data signals to the upstream buffers.24. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 22 wherein reconfiguring said addressed peripheral device and allperipheral devices on said serial bus between said addressed peripheraldevice and said base station further comprises:issuing a start oftransmission command by said addressed peripheral device wherein inresponse to said start of transmission command, said downstream buffersin said peripheral device connected directly to said base station bysaid serial bus are connected to said upstream buffers so that thedownstream buffers pass clock and data signals to the upstream buffers.25. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 24 further comprising:transmitting clock and data signals fromsaid addressed peripheral device to said base station over said serialbus.
 26. A method for sending data and commands to and receiving datafrom peripheral devices connected to a base station by a serial bus asin claim 25 further comprising:reconfiguring said addressed peripheraldevice and all of said peripheral devices on said serial bus betweensaid addressed peripheral device and said base station, upon saidaddressed peripheral device transmitting an end of transmission command.27. A method for sending data and commands to and receiving data fromperipheral devices connected to a base station by a serial bus as inclaim 26 wherein reconfiguring said addressed peripheral device and allperipheral devices on said serial bus between said addressed peripheraldevice and said base station upon said addressed peripheral devicetransmitting an end of transmission command furthercomprises:reconfiguring upstream and downstream buffers in allperipheral devices on said serial bus between said addressed peripheraldevice and said bus station so that the upstream buffers pass clock anddata signals to the downstream buffers.
 28. A method for sending dataand commands to and receiving data from peripheral devices connected toa base station by a serial bus as in claim 27 furthercomprising:reconfiguring said addressed peripheral device so that theupstream buffers pass clock and data signals to the downstream buffersupon said base station transmitting an end of transmission command.